Solidworks Properties in Windows Explorer

Most likely because it is simple.. Right mouse click over the file and click properties, custom or summary.

"Paul Salvador" wrote in news: snipped-for-privacy@mygate.mailgate.org:

I'm aware of that one. I want to see the custom properties in a column in Explorer.

I know it's technically possible. You can write what's called a "column handler" shell extension that allows you to add whatever columns you want to Explorer's detailed view.

I have this memory of getting really excited (in a geeky way) about seeing my "PartNumber" custom property displayed in Explorer and being able to sort on it. Maybe it WAS a dream.

Hmmm...maybe I'll try to write something myself...

Just right-click the column header and put a checkmark next to the column you want to see.

Mike Wilson

"Mike J. Wilson" wrote in news:hZCdnXeR_a9db7iiU- snipped-for-privacy@giganews.com:

I'm aware of that, too. That doesn't show any of the SW custom properties--only the ones from the "Summary" tab and a bunch of properties specific to some well-known media types.

I'm guessing either:

1) I imagined the whole thing.

2) I had done it a different way (i.e. used one of the standard properties to hold the part number).

3) SW wrote a column handler but now it doesn't work with XP.

I'll guess you are combining/imagining the SW Explorer/Windows Explorer functionality?

BTW, it would be nice! Such as, consistency (an strange word which constantly gets overlooked to generate more sp's), if SW Explorer had more of a Windows Explorer look and feel instead of a cheap old funky interface.

For instance, if SW Explorer had similar direct file/directory access instead of sub file/directory windows for browsing. Instead the whole SW Explorer interface is freaking limited.

..

"Paul Salvador" wrote in news: snipped-for-privacy@mygate.mailgate.org:

I never actually used SW Explorer that much. The few times I wandered into it I was never all that impressed. I never understood why it didn't automatically show whatever document I had open in SW.

while sw explorer may not be impressive it has some extremely useful functions. the 2 functions I use most often, renaming files and find where used.

It's definitely useful for renaming and copying dependent links. Without it, well, you can't do the above easily.

But the interface has not really changed in,.. how long? I believe the reason they never advanced SW Explorer was to promote/sell PDM.

Now, with many inexpensive and midrange design tools including PDM or integrated data managment, cheap features like SW Explorer will need to change.

..

It's a pity the API calls for SW Explorer are not readily availiable. If they were we could write programs to view the images and Properties.

-- Tony O'Hara Melbourne, Australia.

"Tony O'Hara" wrote in news:wdFVa.22378$OM3.16841 @news-server.bigpond.net.au:

Why bother with a SW Explorer API? You can do much more with the SW API (which is probably all the SWE is making use of). If someone was so compelled, they could write a much better SW Explorer on their own.

Or are you saying that SWE does things not possible with the SW API? Maybe it has access to "hidden" API's for SW's internal use?

Joel Moore

SWX Exp allows you to access the Config Specific Properties, without opening Solidworks. Whereas, I do not believe you can do this with the regular SWX API. Windows Explorer will only allow access to Custom Properties. The API calls involved in SWX Explorer would provide the methods to do this via Visual Basic.

-- Tony O'Hara Melbourne, Australia.

"Tony O'Hara" wrote in news:wwXVa.1018$ snipped-for-privacy@news-server.bigpond.net.au:

I had to hunt for it but it looks like the CustomInfo2 method of the ModelDoc2 object can be used for accessing configuration-specific properties. But since it was only made available with SW 2001Plus, your point about SWE having access to things the standard API doesn't is still valid.

Thanks for the comment. I agree with you. But I don't have any trouble accessing the info with SolidWorks loaded.

-- Tony O'Hara Melbourne, Australia.

There was already some API code made that used calls from SWExplorer (to access the preview bitmap) and then a SW support guy said it was not a good way to do it, and supplied a .tlb to allow VB access to the preview bitmap.

But the .tlb allowed ONLY access to the bitmap, not all the other goodies contained in the structurd storage.

What you need to do is access the 'stuctured storage' of the SW docs; to get the 'extended' info right from the document, without the need for Solidworks, or Solidworks explorer, to be installed.

MS has a freebie .tlb that allows generic access to the structured storage, but only to a certain depth... if one considers the 'storage' to be 'directories', and the 'streams' to be 'files', then the MS .tlb only allows reading of files in the root directory.

I made my own .tlb, but there are a few others out there, that will allow tunneling down thru the structured storage. Aside from the preview bitmaps, and the config names, there is a HUGE amount of data there:

config info: whether configs are derived, alternate config names, etc

solids: there is a parasolid model for each config

update stamps: there seems to be time stamps for the creation/mod dates for each feature, even when some features were deleted. But this, like the API version, doesnt seem totally reliable.

version history: dlls, versions used, etc

.. and plenty more I havent decoded yet.

Also, aside from the speed increase to get this data, opening from the structured storage gives you more flexibility on knowing ahead of time whether the model is being worked on; you can tune this down to the cinfiguration level (Open and read only if Model is not in use, or open and read only if a certain CONFIG is not in use, etc)

In the .NET section of this guy's site (Eduardo Morcillo) there is a free wrapper for accessing SS files.

Not sure how it stacks up to other implementations but here's a look at the sample app packaged with it (looking at a SW part file):

His test program doesn't display the config-specific properties but I think that's only because he had Office documents in mind when he made this sample.

Joel Moore