How do I set the Custom Property Tab Template from a VB Macro?

[Craig Makarowski]

Can't seem to record macro of when you select a Custom Property Template



Now I select the template



then i get this



All the while I'm recording the Macro, even after I click the Apply button and Save!

This is what i get in the Macro



So none of the Property tab template functionallity gets recorded, I need to be able to control this in my Main Macro

that has a form with values that would auto fill the fields in the Property tab. I can fill in the Custom properties directly from

exsisting code but no Idea how to set the Property Tab Template from my VB code.

I'm using SW2013 SP05 x64bit On Win7

[josh]

sub main()
application.sldworks.activedoc.extension.custompropertybuildertemplate(false) = "whatever.prtprp"
end sub

[Craig Makarowski]

sub main()
application.sldworks.activedoc.extension.custompropertybuildertemplate(false) = "whatever.prtprp"
end sub

wow that was fast and thank you very much!!!

[lenoli]

sub main()
application.sldworks.activedoc.extension.custompropertybuildertemplate(false) = "whatever.prtprp"
end sub
this macro can't run in SW2020?

[gupta9665]

sub main()
application.sldworks.activedoc.extension.custompropertybuildertemplate(false) = "whatever.prtprp"
end sub
this macro can't run in SW2020?

Did you specified the correct path for the property tab builder file with extension?

[lenoli]

Did you specified the correct path for the property tab builder file with extension?

Yes , I have set system option > file location> CustomPropertyfile folder.
and all CustomProperty template show in list but still not working.

[gupta9665]

Yes , I have set system option > file location> CustomPropertyfile folder.
and all CustomProperty template show in list but still not working.

Sorry I meant to ask if you changed the "whatever.prtprp" with your required Custom Property template name with extension?

[T_H2O_mas]

Hi!
After struggling with this particular issue for about half a day, I've discovered that it doesn't like to show whether it succeeded or not.
I tried to use a boolean to show whether it succeeded or not, however that was exactly the thing that prevented it from succeeding.
Just have the line mentioned before, nothing else

[josh]

You are setting a Property of an object. You don't get a return from setting a Property. You only get returns from Methods.

[crimsoncleansed]

Glad I came across the post.

I want to check if it is the desired effect, but when I run this I have to save the file, then close it and reopen it before I can see the Custom Properties template changed out. Is this normal?

Thanks.

[little zombie]

This is because the taskpane is not updated in real time. You can switch the taskpane manually or use the following code.

'close taskpane
swApp.SetToolbarVisibility swToolbar_e.swTaskPaneToolbar, False
'open taskpane
swApp.SetToolbarVisibility swToolbar_e.swTaskPaneToolbar, True

[blackzero007]

In our team, we have saved custom property templates as .asmprp & .prtprp files for assemblies and parts. For the drawings, we have prepared standard drawing templates saved as .DRWDOT in a standard shared location on a network drive.
The problem occurred when the IT changed the network folder address from \\10.100.xx.xx to \\abcxxxx.
All the existing data (thousands of parts, assemblies and drawings) couldn't even be opened because it kept searching for the templates and custom properties files in the old location which didn't exist anymore.
We updated the default file locations for everything, but all in vain. SW was unable to pick up the templates from new locations. It always stopped responding while opening the files. The way-around was to open the solidworks and make sure 'home' is active tab then open. But the moment we clicked on custom properties, it stopped responding. For drawings, there was nothing we could do as they always got stuck.

After lots of hit and trial, we figured out that if we copy the data to a local drive, then disconnect the network (pull the cable / disconnect wifi), we can open the files. Then we could see an error message telling that custom properties template couldn't be found.

Solution we devised:
Open files offline; run a script to re-link the custom properties. The script I picked from the same thread and ran it across the folders and sub-folders. It ran overnight and by the morning, thousands of part and assembly files were rectified. If you want, I can copy the script here.

[mp3-250]

In our team, we have saved custom property templates as .asmprp & .prtprp files for assemblies and parts. For the drawings, we have prepared standard drawing templates saved as .DRWDOT in a standard shared location on a network drive.
The problem occurred when the IT changed the network folder address from \\10.100.xx.xx to \\abcxxxx.
All the existing data (thousands of parts, assemblies and drawings) couldn't even be opened because it kept searching for the templates and custom properties files in the old location which didn't exist anymore.
We updated the default file locations for everything, but all in vain. SW was unable to pick up the templates from new locations. It always stopped responding while opening the files. The way-around was to open the solidworks and make sure 'home' is active tab then open. But the moment we clicked on custom properties, it stopped responding. For drawings, there was nothing we could do as they always got stuck.

After lots of hit and trial, we figured out that if we copy the data to a local drive, then disconnect the network (pull the cable / disconnect wifi), we can open the files. Then we could see an error message telling that custom properties template couldn't be found.

Solution we devised:
Open files offline; run a script to re-link the custom properties. The script I picked from the same thread and ran it across the folders and sub-folders. It ran overnight and by the morning, thousands of part and assembly files were rectified. If you want, I can copy the script here.

have you tried mapping a network drive? \\ network paths have a lot of compatibility problems. using a nwtwork drive will point to the same place, but it mimic the local drive behavior so even very old scripts and programs could run like it was a local path.