API == Folders

swTnFeatureFolder _T("FtrFolder")

swTnSurfaceBodyFolder _T("SurfaceBodyFolder") swTnSolidBodyFolder _T("SolidBodyFolder")

im sure the items in the folder are child of the folder

retval = Feature.GetChildren ( )

The features inside a folder are not children of the folder feature. Instead, for each feature there are two "feature folder" features. You can easily see the how the folders work if you traverse the features by using Feature::GetNextFeature. For example, if there is a folder named "Folder1" in the feature manager tree, there is two folder features named "Folder1__StartTag__" and "Folder1__EndTag", and the features "inside" the folder are beetween these features.

To see whether a feature is in a folder, you have to traverse forward the feature tree until you find a "FtrFolder" feature. If it's name contains "__EndTag"__" the feature is inside a folder. The following function can be used to get the name of the folder in which a particular feature is. The function returns an empty string if the feature was not in a folder.

Hope this helps!

Function GetFolderName(ByVal objFeature As SldWorks.Feature) As String 'Loop forward in the feature tree until a folder feature is found While Not objFeature Is Nothing If objFeature.GetTypeName = "FtrFolder" Then 'A folder feature was found, see if it is an "end tag" folder If InStr(1, objFeature.Name, "EndTag") Then 'Split the folder name from first "_" character GetFolderName = Left(objFeature.Name, InStr(1, objFeature.Name, "_") - 1) Exit Function Else 'If the folder was not an "end tag", it must be a "start tag" and therefore the feature is not in a folder Exit Function End If End If 'The feature was not a folder feature, so get the next one Set objFeature = objFeature.GetNextFeature Wend 'If we get this far, there was no folder features after this feature End Function

"Sean Phillips"

wrong! ;-) if you check the Parent/Child of a feature in a folder, the folder isn't listed in the Parents, and the folder has no Parent/Child.

Run this small macro to see how it is done :

Sub recurse(ByVal f As SldWorks.Feature, i As Integer) Debug.Print Space(i); f.GetTypeName; "/"; f.Name Set f = f.GetFirstSubFeature While Not f Is Nothing Call recurse(f, i + 2) Set f = f.GetNextSubFeature Wend End Sub

Sub main() Set swApp = Application.SldWorks Set Part = swApp.ActiveDoc Set f = Part.FirstFeature While Not f Is Nothing Call recurse(f, 0) Set f = f.GetNextFeature Wend End Sub

you'll get something like this :

DetailCabinet/Annotations CommentsFolder/Comments DocsFolder/Design Binder MaterialFolder/Material EnvFolder/Lighting AmbientLight/Ambient DirectionLight/Directional1 DirectionLight/Directional2 SurfaceBodyFolder/Surface Bodies SolidBodyFolder/Solid Bodies RefPlane/Front Plane RefPlane/Top Plane RefPlane/Right Plane OriginProfileFeature/Origin ProfileFeature/Sketch1 FtrFolder/Folder1 Extrusion/Extrude1 ProfileFeature/Sketch1 FtrFolder/Folder1___EndTag___

you'll notice:

1) surfaces and bodies listed in Surface/Body "Folders" are not really "features" 2) lights are, and they are actually subfeatures of the "EnvFolder/Lightning" feature 3) sketches are called "ProfileFeature" and are listed once at the main level and once as subfeatures of the features based on them... 4) features folders are implemented by 2 "FtrFolder" features with matching names delimiting the list of features they contain ... 5) if may happen (as above) that a sketch listed in the folder in UI is actually out of the folder in the features list...

So to know if a feature is in a folder, you should scan the features and check if you find the feature between some FtrFolder x /FtrFolder x___EndTag___ pair of features.

I'm still trying to guess the design intent behind this somewhat incoherent handling of features. It seems that for some reason SW doesn't use a real tree of features but is stuck to a single level of subfeatures...

Hey Heikko, don't you have better things to do on Sundays than answering the same posts as me ? ;-)

Hey guys, I don't mind at all. :)

A couple interesting side notes.

I ran into this problem because I wanted to write a small macro to move enmasse a group of features into or out of a folder. In my particular practice I roll back to just after the last feature in a folder, create more features based on the features in the folder and want to keep them all together. Horizontal modeling I think this is called.

I asked SW about this problem and they were not aware of the fact that folder tags can be enumerated. It isn't in the documentation and there are no specific API calls regarding manipulating folder contents. Thanks for all the effort (in VB). I appreciate the C stuff, but can't really use it since I am limited to VBA right now.

I will check to see if I can move the folder tag after my list of features there by encompassing the features in between. That would be easier and computationaly cheaper than moving the features up past the tag.

If the folder feature end tag can be moved I w> Hey Heikko, don't you have better things to do on Sundays than answering

Heh, it's the famous "Get a Life"-syndrome (tm) ;-)

Btw, I don't mind about misspelling my name, but just for curiosity - "heikko" happens to be Finnish and means "weak". :-D

I have wondered this as well. Maybe the reason could be the fact, that you can easily make a mess of the folder tags, eg...

Folder1__StartTag__ ...features... Folder2__StartTag__ ..more features... Folder1__EndTag__ ..Even more features.... Folder2__EndTag__

The UI and API calls should prevent this kind of problems.

-h-