API - Set configuration-specific custom properties 2

[NanoMan]

As best I can discern, one can only read a configuration's custom properties programatically, not set them. Am I correct? I sure hope not...

 

[TheTick]

Not correct. Have you read the API documentation?

retval = ModelDoc2.AddCustomInfo3 ( configuration, FieldName, FieldType, FieldValue )

ModelDoc2. CustomInfo2(configuration, fieldName) = value

For "general" (file-wide) properties, configuration parameter should be an empty string.

Also note: AddCustomInfo3 does not overwrite existing properties.

There are two types of people in the world: the kind that believe that people can be categorized into one of two groups and the kind that don't.

http://www.EsoxRepublic.com

 

[NanoMan]

Thank you for your prompt answer to my question.

In response to yours, I'm working at reading it. I'm finding it to be a bit laborious and not organized quite the way I'm used to seeing some VBA docs.

I did figure out how to use a For...Next loop to add configs and descriptions; I was able to read the custom properties for each but couldn't find the info you referenced.

The biggest problem is that I'm trying to learn on the fly while keeping my boss at bay ("Why aren't you done yet?? We bought this new tool for you!! Learning curve, what the *#% is that??")

Thanks again for your quick response. I regret that I have but one star to give for my benefactor.

 

[TheTick]

Well, I cut-and-pasted right out of the SW API help. It may take a bit to get used to SW's help syntax. Remember that the VB command is the "OLE" and not the "COM".

Pay attention to return value data types. Don't use variants unless specifically called for. For that matter, always use the specific data type that is called for (boolean, long, etc.)

Early binding of objects (are you still with me?) helps loads. Whenever possible, define objects specifically, i.e. use Dim swApp as SldWorks.SldWorks rather than Dim swApp as Object. That way, the available properties and methods come up as soon as you type that dot after the object. Also, have you discovered the joys of ctrl-J in the VB editing environment, yet?

The only hitch with early binding and SW API is with file SW objects. SW models are really two objects, i.e. a part is a PartDoc and a ModelDoc, which means that you do need to "Dim" them as Object. One alternative: I have recently started wrapping SW docs in a class object that gives access to early binding for all of the subobjects. If you are interested, I will post it to my website.

There are two types of people in the world: the kind that believe that people can be categorized into one of two groups and the kind that don't.

http://www.EsoxRepublic.com

 

[macPT]

I would mention (I was stuck here for a while when first dealing with this), if you want to change the value of an already assigned custom property, you must previously delete it:

retval = ModelDoc.DeleteCustomInfo2(ConfName, propertyname(i))

Then set it again with the new value. Otherwise the changes will be ignored.

Regards

 

[TheTick]

MacPT:

Are you sure about this? I have working programs where ModelDoc2.CustomInfo2 works just fine for changing properties. I would be interested to see a situation where it fails. Also, refer to my first post on this thread re: AddCustomInfo does not overwrite existing properties.

 

[macPT]

TheTick
I just tested my macro and it behaves like I say. If I disable the line for deleting the property with an assigned value, the new value is ignored. I need to enable the line to delete the custom property and recreate it with a new value.

But maybe I am not reading your mail correctly: what do you mean by "changing properties" and by "overwrite existing properties"? I am missing something in your post.

Regards

 

[NanoMan]

TheTick / macPT:

Interesting... I just found that there must be an existing custom property in order for it to be set. When there were no configuration-specific custom properties set, the ModelDoc2.CustomInfo2 did not work. When the custom property field had something in it, it did work.

I tried several times both ways and I'm fairly confident of the result.

TheTick: I am interested in the Class-object approach and would be grateful for any guidelines, info, or code you post.

 

[macPT]

We are having different experiencies and I'll give more detail to understand the different aproaches. I create 61 custom properties using an excel worksheet, each line is a property, each column is a configuration.

1- In first place, after click on the "read properties button", the macro fills the contents of all properties for all existing configs (after model creation, these are all empty, leaving the excel cells empty)

2- Then, in normal excel use, I change the cells contents as I want. Excel is a good tool for this because some properties can be calculated using excel formulas, other can be easely controled (like the length of the field) and I can use copy/past to reproduce properties over several configs.

3- In the end I click on the "update properties button" and the following happen:
3.1 - the macro delete all the properties (even after model creation, but they don't realy exist yet)
3.2 - the macro create each property, for each config, with the actual content of each cell
3.3 - the macro repeat step 1 in order to confirm that SW understood the input.

If I miss step 3.1, no matter the input in 2, step 3.2 will fail and step 3.3 will show the properties before update. So I need to delete the properties and create them, again, with the new values for a proper update.

Can this aproach be giving different results from others using the same commands?

Regards

 

[dogarila]

Are you guys talking about the same thing?

AddCustomInfo3 or CustomInfo2 ?

 

[TheTick]

'CUT, PASTE, AND RUN THIS MACRO
'make sure there is an active document
'check properties at each Stop
' ***************************************************
' Experiment to show overwriting of custom properties
' ***************************************************
Dim swApp As SldWorks.SldWorks
Dim Part As SldWorks.ModelDoc2

'custom info types
Public Enum swCustomInfoType_e
swCustomInfoUnknown = 0
swCustomInfoText = 30 ' VT_LPSTR
swCustomInfoDate = 64 ' VT_FILETIME
swCustomInfoNumber = 3 ' VT_I4
swCustomInfoYesOrNo = 11 ' VT_BOOL
End Enum
Sub main()

Set swApp = Application.SldWorks
Set Part = swApp.ActiveDoc

'start with part that does not have a property named "TestProp"
Part.AddCustomInfo3 "", "TestProp", swCustomInfoText, "Add"
Stop
'stop to check active doc's properties and see if "TestProp" was added

Part.CustomInfo2("", "TestProp") = "Change 1"
Stop
' "TestProp" should be changed to "Change 1"

Part.AddCustomInfo3 "", "TestProp", swCustomInfoText, "Change Back"
Stop
' "TestProp" should still be "Change 1" and not "Change Back"

End Sub

 

[macPT]

TheTick
Now I see your point and understand what you're saying. We have different procedures.

Your procedure to change the property (and that's the actual correct procedure - I didn't realised that) is using Part.CustomInfo2. But this was only made available in SW2001Plus. I wrote this macro for SW2000 and, at that time, the availability to change the properties was using Part.AddCustomInfo2. In that case we needed to previously delete the property (or the value would not change like you say in the last part of the macro example).

As this macro is still working OK, even in SW2004, I never bother to keep up to date with the actual procedures. I am sorry to mess up this thread.

Regards

 

[TheTick]

I wouldn't change it if it works. Most of the subroutines I wrote to modify properties double-dip the add and change methods, since "change" doesn't add and "add" doesn't change. Also, it is not possible to change an existing property type (i.e. from text to yes/no), so that often forces a delete/add in order to change a property.

I still have SW2001 running at home. Whenever possible, I try to keep things compatible as far back as I can.

There are two types of people in the world: the kind that believe that people can be categorized into one of two groups and the kind that don't.

http://www.EsoxRepublic.com

 

[TheTick]

I decided to post the macro version of my Copy Custom Info utility. The addin version will get posted eventually.

http://www.esoxrepublic.com/freeware/

There are two types of people in the world: the kind that believe that people can be categorized into one of two groups and the kind that don't.

http://www.EsoxRepublic.com

 

[macPT]

Nice macro! Tanks for sharing.

Still I will dare to give a suggestion: instead of opening the target file and select the source file, open the source file and then select one or more target files. Then the macro would batch open each file and change the selected properties (I have something like this using DSOfile, but this is unable to work with config dependent peoperties).

Am I being to bold? My macros, although very useful, are very basic and straightforward regarding code (that's why I use Excel a lot - this way I don't need all that knolege to program forms and control input). Right now I can't say if that would be possible in your macro.

What is your opinion?

Regards

 

[TheTick]

I'm sure I could switch it somehow. The purpose of that program was to populate properties into new parts as they are created. This works well with our (my day job employer's) design cycle and limited number of parts per project.

If I intended to sell the program, I would probably change a few things, like you recommended. As a freebie, it exists to educate and help where it can.

Glad you like it. Enjoy.

p.s. There is a program out there called "Propagator" that does just what you say.

http://www.customsolids.com/Propa-Gator.htm

The person who pragrammed this is a friend of mine and I wouldn't feel right about infringing on her sales.

There are two types of people in the world: the kind that believe that people can be categorized into one of two groups and the kind that don't.

http://www.EsoxRepublic.com