Some of our users think it's a good idea to modify custom properties which are read only on the data card through the custom properties command inside of Solidworks. I need a way to block this. Anyone have a solution? Preferably it would be something that is easy to deploy.
David, you're in luck. I have been needing a reason to write a blog post and this sounds like a great topic. I'll create a blog post in the next couple of hours along with a functioning addin and hopefully it will be useful to you. If you want further modification then you can email me and we can discuss your needs.
I got a good chuckle out of your avatar BTW. RIP MySpace. lol
Keith
Keith Rice wrote:
David, you're in luck. I have been needing a reason to write a blog post and this sounds like a great topic. I'll create a blog post in the next couple of hours along with a functioning addin and hopefully it will be useful to you. If you want further modification then you can email me and we can discuss your needs.
I got a good chuckle out of your avatar BTW. RIP MySpace. lol
Keith
Thanks Keith! I look forward to the blog.
And yea... Tom was good to us... We didn't know how lucky we were, haha.
Here you go, David Lane
In a freebie like this I don't have time to implement the ability to pre-load a block file, but that would be a nice modification and if you're interested in something like that, please reach out. Shouldn't take too long to implement.
Keith Rice awesome! I just watched the video and it seems pretty good. Just need to figure out how to deploy this as an admin. Obviously I can write a script to do the installation, no problem with that.
A few questions I have... Is the text in the command blocker window stored in a text file somewhere (I looked in the installation folder, appdata folder, user directory, and registry)? Reason I ask is I'd like to store the company settings in the vault (having the users get latest on login automatically)... then copy that and overwrite the user file. If it can be modified in a text editor then it would be possible to even block the command blocker command, which obviously I wouldn't want users modifying on their own.
Also... would it be possible to put a password protection in place either per command and for all commands? So if a command is blocked, but the user enters the correct password it still allows the command?
Last question... can there be commented out lines? This would help with notes about what each command is or why it's blocked.
Edit: Also this... Tried replacing the Scale command with a ModelRescaler macro I have. The macro runs; however I get an error when finished.
Run scale from search box. Macro opens form. Apply changes works. Zoom All also works.
When I click close I get this.
Thanks!
Reason I ask is I'd like to store the company settings in the vault (having the users get latest on login automatically)... then copy that and overwrite the user file.
would the settings administrator work for you here?
2019 SOLIDWORKS Installation Help - Settings Administrator Tool
You misunderstood my question... I mean the settings for add-in that Keith wrote, not the Solidworks settings. Thanks though.
David, I hope it is helpful.
Remembering the the text in the user form is handled by .NET and I believe the data is stored in Users\<user>\AppData\Local\Dassault_Systemes, but you might have to do some digging. In a modified version of the software this could be adapted to run from a network drive, but I didn't have time to implement that on a first go round.
You are correct that the command blocker itself could be blocked, in which case you would need to delete the AppData folder I alluded to earlier. Reinstalling might also rewrite the app settings but don't quote me on it.
Yes, aside from allowing the CAD admin to reference an external file on a network drive, it is possible to add password protection and commented lines, though I'm a bit maxed out right now so if this is a serious need then please email me at keith@cadsharp.com so we can discuss further. I don't think these updates would take too long and I'm willing to include the source code if you decide to use us for consulting.
I couldn't tell you off the top of my head why that macro is giving an error; the API call used to run an external macro (ISldWorks.RunMacro2) delivers an error code so you could set up a macro to test that API call with ModelRescaler.swp and see what it is.
Keith
Hi Keith, I wanted to report an issue with the add-in. Opening the settings for the add-in is a command of 1625. If admins want to block this, it is a problem because 1625 is used for the Solidworks PDM add-in commands as well. If you right click the file name at the top of the model tree, and use any command in the Solidworks PDM menu they are all blocked. I don't know if this is something that can be fixed easily or not, but wanted to point it out.
If they're unemployed they wont be changing locked things.
Oh, that's helpful. Threaten to fire them because they follow practices taught to them in Solidworks training courses.
David Lane wrote:
Oh, that's helpful. Threaten to fire them because they follow practices taught to them in Solidworks training courses.
There are only three possibilities here.
1. You failed to tell them the right way.
2. You told them and they forget.
3. You told them and they still do it wrong on purpose.
1 is solved by doing your job.
If 2 can't be addressed without a software lockdown, you need to question their competence in other areas.
If 3 is the case, yes. Fire them. On the spot.
SolidWorks is, in general, a program that trusts its users. There are very few ways within SW to lock things down or prevent people from doing things.
Josh. You can stop. Be helpful, not arrogant.
We recently transitioned to SWX from Creo. In Creo there were not data cards, everything was changed using a command similar to the properties command in SWX; however in Creo many of the properties could be locked and controlled by the PDM system (Windchill in this case). Nothing can be locked in SWX as far as I know.
Also we have users in different countries so communication is a challenge. There is a local admin in those locations, but still there is a lot of miscommunication. Also, I don't have the authority to fire anyone and even if I did I wouldn't. Solidworks should have the ability to lock down certain things like this and preventing modifications to sheet format. Most users wouldn't know how to change this stuff to begin with, but then we send them to Solidworks Essentials training and then they learn all these things because the classes are setup to train people who aren't using a PDM environment.
Perhaps I'm misunderstanding why this is in API/Macros. I think in the property tab builder you can use the list feature which allows only what is offered to the list property file (txt or excel):
So how does this prevent them from changing the revision variable for example? PDM should be the only thing controlling that.
David Lane wrote:
So how does this prevent them from changing the revision variable for example? PDM should be the only thing controlling that.
I see. If you set up the file card in the admin tool, you should be able to make the variable read only in different workflow states.
It's read only all the time. But users can still use this command to change anything they want.
Unless I'm missing something using the custom property tab builder doesn't prevent this either. I don't think custom property tab builder does anything that I'm not already achieving using the data card. I can already have lists, radio buttons, etc. using the data card.
you are correct.
specific to revisions, the typical workflow in PDM would "correct" the rev the next time the file was transitioned to a rev setting state. but it can certainly lead to confusion/errors in the meantime.
Got it. That will take care of one of the variables.
I dont know anything about API or methods of blocking, just wanted to point out that you can access Cust Prop with a mouse gesture and key board short cut. So make sure to block them (I mouse gesture it, never used the button on the ribbon here)
Might consider blocking elements of Configuration Properties too... I had to clean up hundreds of part properties that were over-written there
I believe the command is the same no matter how is it accessed.
Here you go, David Lane
Command Blocker addin
In a freebie like this I don't have time to implement the ability to pre-load a block file, but that would be a nice modification and if you're interested in something like that, please reach out. Shouldn't take too long to implement.