Macro in the PDM Vault

[christian chu]

Any of you here have tried to save macro in the PDM Vault so other users can use?
Thanks

[gupta9665]

This should work but I prefer to keep it local on user machine as sometimes when more than one user is trying to use a commonly placed macro, the results are weird. I have recently experienced this, so moved the macros to induvial machines and they are working good.

Further I would advise to create an add-in if possible.

[SPerman]

All of my macros live in the vault, but I'm a one man show so there wouldn't be any access conflicts.

[bnemec]

Very much agreed to prefer add-in over macro.

As for running the macro from local disk. Wouldn't that be the case if the macros are in the vault? There is no file sharing with vaulted files, everyone works from local cache.

Well, I guess there are plenty of times where two processes on the same host might be trying to access the same local file...

[christian chu]

This should work but I prefer to keep it local on user machine as sometimes when more than one user is trying to use a commonly placed macro, the results are weird. I have recently experienced this, so moved the macros to induvial machines and they are working good.

Further I would advise to create an add-in if possible.

I have some macro which I've changed frequently so I don't want to add to the addin. I saved on the server so other uses can use without updating to the local drive for each change I made. it's been yrs without issue
I'm thinking of putting macro in the Vault for 2 reasons:
1. Macro can be updated for all users
2. The users can use the macro while being offline from local catch

[loeb]

What are you guys talking about an "add-in" instead of a macro?

[bnemec]

What are you guys talking about an "add-in" instead of a macro?

Add-ins use the Application Programing Interface (API), a set of classes exposed by the software company that allows 3rd parties programmatically control the running application. Add-ins are most typically written now-a-days in a .NET language such as C# or VB.net (not VBA) and commonly written using a Integrated Development Environment such as Visual Studio, but can be simply typed in notepad and compiled from the command line if one really wanted to. There are many third party add-ins for example the Solidworks PDM Add-in is written by the PDM folks using the Solidworks API. There are "Task Add-ins" for PDM. Even the Outlook add-in for MS office or the MS office add-in for Outlook.

Macros are, in my over simplified terms, recordings of actions that are replayed. Typically it's some form of VBA that is "compiled" or interpreted by the application often at runtime. Where an add-in is compiled and built into .dll(s) that are registered by the Windows OS and loaded by the application either at startup or when needed. Macros are often written and edited in some editor that is part of the host application and debugging is typically very limited in comparison to add-in developed in a IDE.

There are many differences once we start getting into the details.

[SPerman]

I would argue that each have their place. Spending the time to turn my "Save as PDF" macro into a add-in would not be a good investment of my time. (Although I guess if you have hundreds of users there may be good reason to invest the time even for something simple.)

[AlexB]

Keeping a macro in the PDM vault should be no different than having it individually on each user's PC outside of the vault. The function of PDM is to eliminate the network from the picture when a user is interacting with solidworks files in the PDM vault. To do this, it caches files locally to your C: drive and accesses those directly in order to read/write depending on the permissions that PDM allows for the specific file state.

Macros are typically simple but can be very complicated and the VBA editor is sometimes preferable for some applications of the API. It's best suited for scenarios where you always want to do the same thing to a file with minimal customization for the user to apply. For example, there's a macro floating around to hide all reference objects (sketches, helixes, planes, origins, etc.) and it has a checkbox next to each type the user can choose to hide. In the end, it does one thing which is to hide the things you want to hide.

Add-ins are typically highly customized in the sense that it can do many things to many different types of files. For example, we have one we use internally that acts as a custom property editor but also can update our old formats to new templates and batch export different file types to a specified network location based on project. These require a good understanding of c# or vb.net as well as API programming in general which makes them a no-go for your average SW user.

There are pros and cons of both, but add-ins are a lot more complicated to create than a macro.

[jcapriotti]

We keep most of macros in PDM with the folder set to cache latest on login. Generally works pretty well. The only catch is if you check-in a new version, we have to tell everyone to cache the latest, or logout and back in as the auto caching only triggers on login. Be nice to have a push function.

[bnemec]

We keep most of macros in PDM with the folder set to cache latest on login. Generally works pretty well. The only catch is if you check-in a new version, we have to tell everyone to cache the latest, or logout and back in as the auto caching only triggers on login. Be nice to have a push function.

I think a "push" function could be done using PDM add-in but would be hack. It would be it's own add-in because it would need to run once on each machine and each machine would need to be set as a task host for that add-in. Problem is I don't know how to control which host runs the task without manually changing it in the admin tool for each machine.

Alternatively and even more hack would be an add-in that is triggered by some probably not related thing and do the get latest in the OnTaskLaunch. Problem with that is what to use as a trigger?

Last one that I can think of is a stand alone exe that uses PDM API to get latest of the macro (entire folder probably) and that exe is called from a one-shot scheduled task that is pushed out to all the clients, similar to how the admin image can be started.

I don't know that any of those options are worth while or better than just telling everyone to go get latest of the macro.

Edit: There are several places where the Solidworks PDM Add-in could have some finishing touches applied. Caching some of these other file types that the Solidworks process reads/writes would be helpful. Templates, formats, macros, hole wizard tool file, etc. Not just caching, but the add-in should make Solidworks aware that those files are in a local vault, not just a file on local disk. When SW tries to touch those files PDM add-in should kick in and get cache or ask to get cache as well as if user wants to check them out or change state if needed. I think I have this in my PDM TTL.

[jcapriotti]

@bnemec Some these we considered in the past. I can't see Dassault adding much more to PDM when they'd rather move everyone to their cloud PLM platform.

Since we are moving to Windchill, we will no longer be able to store the SolidWorks configuration files in a vault. WC has some ability to do this but it doesn't work well and has performance issues. Likely we go back to storing the files in a folder on the user's c drive and push out updates using InTune.

[mp3-250]

macro in the vault and no problem so far. that folder is set to get latest version on login.

[andrmollo]

We store our macros in a PDM folder set to get the latest version on login. Works fine with 35 or so macro in a 10 users environment.

This also allow me to have the macro files permanently checked-out so the other users can't mess with them; I can also experiment new features in my local cache and then check-in the macro when it is stable for my colleagues to use.

[christian chu]

We store our macros in a PDM folder set to get the latest version on login. Works fine with 35 or so macro in a 10 users environment.

This also allow me to have the macro files permanently checked-out so the other users can't mess with them; I can also experiment new features in my local cache and then check-in the macro when it is stable for my colleagues to use.

Thanks for the info.

[christian chu]

I would argue that each have their place. Spending the time to turn my "Save as PDF" macro into a add-in would not be a good investment of my time. (Although I guess if you have hundreds of users there may be good reason to invest the time even for something simple.)

I think the idea here is not developing an add-in just for "Save As PDF" but adding this feature "Save as PDF" to an existing Add-in - see att. image - I have one add-in for all features in 3D and 2D
By the way, you can use add-in to load the macro as I believe you are aware of it

[DanPihlaja]

I would argue that each have their place. Spending the time to turn my "Save as PDF" macro into a add-in would not be a good investment of my time. (Although I guess if you have hundreds of users there may be good reason to invest the time even for something simple.)

It may not be a "turn this macro into an add-in", but instead be a "create an add-in that accesses all the macros and runs the one you select"

[AlexB]

It may not be a "turn this macro into an add-in", but instead be a "create an add-in that accesses all the macros and runs the one you select"

Artem has already developed and add-in that does this. I believe it's free, but I could be wrong.
https://cadplus.xarial.com/toolbar/