SLDPRT/SLDASM files formats?

"Olivier L." wrote: First, do not take care of my english, I'm french :) ok... do the same for me, I'm swiss (french too)

Good luck...

When I asked SW Corp, thy said "This is not public, and varies with versions". Nobody to my knowledge could manage to reverse engineer the format. Products like

and claim "native" support of SW formats, but require the product to be installed (in fact they start a hidden SW session) My suggestion is to use another format to store the data you need and keep it synchronized. My project is just about this subject. e-mail me for more info.

I have asked this too, SW corp is not willing to give public specifications about their files. In my opinion this is quite acceptable, because if the SW file format would be public, they would have to stay in that format. Now they have the freedom to tinker with the format whenever they wish. Nothing prevents you from reading SW files, someone even mentioned that he was able to read configuration specific custom properties without SW application. But if SW corp decides to change the format somehow, it is your headache...

It is indeed possible to read something from SW files, I believe that for example the preview images, parasolid & edrawing data can be read rather easily.

-h-

Why?

Why do you consider that a good thing?

Jim S.

I do a partial (selective ?) read on a near-daily basis. I have to "nest" large assemblies/ export flat patterns over a slow internet connection, and I do a quick verify of all related documents by peeking into the IStorage beforehand, checking for config names/mod dates, etc, before running this long operation.

There is a .TLB, and related source code, at :

reads Storage/Stream info.

All the storage names are "man-readable", and can give you an overview, but you'll have to do a bit of reverse-engineering to translate the data out of the streams.

I found the inconsistent use of UniCode in the streams, of pre-2004 documents a bit hard to work around.

Well, it was just my opinion, you don't have to agree. Maybe I was thinking the subject from their point of view. I'd be very happy to be able to read SW files directly, too.

-h-

Like HTML, which never depreciates tags. (No, wait, they do)

I think the real reason is to prevent someone from making a version receding translator. That way everyone has to upgrade every time a client upgrades.

Joe

"Someone" could always use the API to write, say an XML file with all the info in it, then rebuild the model from the XML on a previous version... or on a different CAD. All it takes is a lot of work. You're welcome to contribute the

open source project.

Why can't your site be used with mozilla 1.6 Al new standards are availible (CSS, etc...)

Johnny

Actually, the code to read the native SolidWorks drawings, parts, and assemblies is available to anyone who is a part of the SolidWorks Partnership program. There are a number of software vendors who take part in this program.

Applications like the ModelPress Publisher do in fact support the reading of the native SolidWorks files without the requirement of any SolidWorks CAD session, SolidWorks CAD installation, or SolidWorks API components installed. ModelPress Publisher, like the Myriad viewing product(also produced by the makers of ModelPress), extracts the geometry and other attribute information directly from the SolidWorks files.

To my knowledge, SolidWorks does not provide the code that reads the part and assembly files unless you (your company) has signed up with their Partnership program. I'm not sure what all is > First, do not take care of my english, I'm french :)

I think you can use SolidWorks Viewer to view a SW file. However, you can not modify it. Or, you can ask your design supplier to give you the eDrawings format file, then you can view it with eDrawing software, it is free.

Raymond