CAD Forum

I would like to understand a little better where and when Solidworks settings are used.
Solidworks pulls settings from a lot of locations depending on the user action.
I am focusing on CAD only, excluding PDM, simulation and edrawing from this discussion.

At the end of the day I prefere to have my company SW settings in a readable format, possibily plain text, or a REG file instead of relying on native files only. Native files are basically black boxes and it is difficult to make comparison at glance, having to dig all the settings screen in modelling assembly and drafting as you could miss some hidden option here and there.
This is why I am doing this kind of work, just to clean up all the garbage inside our data and keep track of what must be preserved from one CAD version to the next one.

---
My understanding is that SW system options are stored on a per windows user base inside the windows registry under the "factory defaults" (sort of, since they seems to be missing some keys the user creates when using SW) are stored under This is the simplest part and I am managing our company defaults pushing reg files to there.
But looking a bit closer to the above registry keys there are comprised by a lot of subkeys.
Depending on your installation there are over 15,000 unique settings including menus, toolbars, command manager, and other UI customizations. Splitting them in "System option" and "UI and other customizations" makes them more manageable.

Many System Option settings fall under this key and the below subkeys: User interface is mostly (not all) under the "\user interface" subkeys.

There are some specialized subkeys like but a lot of system options are just thrown under general together.

This is the simple part, and I think I got it.
What I do not understand is how other specialized keys are used by SW. Take: This key contains what seems to belong to "document properties" not the "system options": arrow dimensions, center mark dimension, virtual sharps. When I remake my templates I need to import all those settings from our drafting standard file, so why are they there and when are they used? On what values are they setup? Are they a dump from a previously used template in case no template is selected in SW?

Dimension settings and other document related properties are saved inside the templates files, but roughly half of them can be saved to a drafting standards file.
So having to remake from scratch the templates for the second time, and considering the last time I missed a couple of options (out of 1500+) causing some annoyance in the company, this time I figured out to extract all the documents properties from our existing template using API and I was able to compare the new template (currently under remake) and the legacy one dumping all the settings in two txt files and comparing for differences.

Document settings are apparently divided by data type so you have settings divided in:
DOUBLE
INTEGER
STRING
TOGGLE
TEXT FORMAT(font objects and all their settings)

API Help have ALL the properties methods explained and for each of them the property enumeration (they are solidworks version dependend, sorted by name and there are "internal use only" and "obsolete" properties as well, so be careful when comparing apple with oranges...).

DOUBLE METHOD
https://help.solidworks.com/2022/Englis ... Redirect=1

DOUBLE ENUMERATORS (for the types below I will skip enumerators as they are linked in the method page)
https://help.solidworks.com/2022/Englis ... lue_e.html

INTEGER
https://help.solidworks.com/2022/Englis ... teger.html

STRING
https://help.solidworks.com/2022/Englis ... tring.html

TEXTFORMAT
https://help.solidworks.com/2022/Englis ... ormat.html

TOGGLE
https://help.solidworks.com/2022/Englis ... oggle.html

SAMPLE CODE BUTCHERED FROM API HELP JUST TO SHOW HOW TO GET PROPERTIES
I am working on a more comple macro with UI, but the concept is to dump all the properties and values inside a textbox then compare with notepad++ or winmerge the results from two different templates.
It took a while to figure out how this works, I think I understand SOME of the logic behind it, but I still have not figured it completely. For example your dimension line font in drawings is defined as both INTEGER (line font selection from a drop down menu in which the number is the selected item position) and a DOUBLE (the line font thickness value in meters).
This makes sense: integer value saves the UI configuration and the double value the real property value itself.

Apparently System option Settings and Document properties seems to be also mixed up in those categories and I ended up dumping all of them, often wondering if I am looking at the current document properties or my system settings. This is quite confusing.

The complete dump for most of the above properties (it excludes font settings like italic on/off etc) is already 1800 lines long. I think was able to compare the document properties of two templates made in SW2022 and SW2023, and I was able to find some mistake I made when I manually set one of our new template, but I am not 100% sure yet if I am looking in the right way to all those data.

DOUBLE and INTEGER apparently comprise most of the settings included in document properties and seems coherent with the UI for document properties.

STRING type values (form meat least) are almost empty with the exlusion of a few properties like the name of current drafting standard, units of measure etc.
There are few dialogs like that in Document properties UI so it is probably ok?

TEXTFORMAT gathers all the font related settings so you have to look for every single font related property to be able to properly check them. I locked at swTextformat.TypeFaceName and swTextformat.CharHeight to gather Font name and character heigth and it seems to work as expected. We had some View font mistakenly set with a different font and size compared to our standard and it was discovered at glance.

The TOGGLE category seems to gather most of checkboxes under system option, so ignoring them is probably safe?
My main struggle is with this TOGGLE, I am trying to understand some incoherence I have noticed.

In my registry I have this SW settings Dumping the UserProperties with API I got
So my registry (actual SW settings) and the dump from API with regards to TOGGLE category do not match apparently. I tried to change those two options in SW and the registry updates as 0 when I uncheck them, but the API still returns FALSE for both swAssemblyAllowComponentMoveByDragging and swAssemblyAllowCreationOfMisalignedMates. Where does this FALSE comes from?
There are a lot of other settings in toggle and some are TRUE and some other FALSE, but I cannot rule out I am reading only some garbage.

https://help.solidworks.com/2023/englis ... Redirect=1

the enumerators are apparently the same for both document properties and system option, but the method to get them is different. I think you still get some value not really used, but at least now I undestand better.
System Option - ISldworks Document Properties - ImodelDocExtension

Looking at your line of thought with the posts and threads you make, it seems that you are trying to figure out what are all the conflicting factors to then point them out efficiently to SolidWorks.

Either that or you're looking to take the SolidWorks code and refine it and remove the ambiguities from it

@AlexLachance I am the PDM admin and "I had enough". We had all sort of troubles and little by little we are fixing them. And I am trying to push SW devs as well as my VAR as we pay a lot of money in license fees etc and we need to make them pay back.

I am developing my own tools as I am basically alone doing the administration of 70+ active seats from deployment, to training and server maintenance and backup. I need to automatize and have solid tools (no phun intended) at hand to minimize manual labor and avoid errors I would have to fix later.
The more I develop the more I understand how SW is working behind the scene.
And it is quite a mess from my amateurish pov. (I am a mech eng not a programmer)

mp3-250 wrote: ↑Mon Feb 12, 2024 8:13 am @AlexLachance I am the PDM admin and "I had enough". We had all sort of troubles and little by little we are fixing them. And I am trying to push SW devs as well as my VAR as we pay a lot of money in license fees etc and we need to make them pay back.

I am developing my own tools as I am basically alone doing the administration of 70+ active seats from deployment, to training and server maintenance and backup. I need to automatize and have solid tools (no phun intended) at hand to minimize manual labor and avoid errors I would have to fix later.
The more I develop the more I understand how SW is working behind the scene.
And it is quite a mess from my amateurish pov. (I am a mech eng not a programmer)

I feel you mate. I'm the CAD Admin for 12 seats and take care of all the stuff you mentioned, I'm no programmer, but I do understand a bit of programming and most of it's logic. Defining how we work helped a lot in defining issues as well.

API settings may not correspond to registry setting.
One or the other may not get updated when those settings changed.

Some registry settings got moved to different subkey in different years.

Some keys with "default" value may not show up in registry.

Registry keys is first build and set AFTER SW first started and CLOSED.
NOT during installation.

So you'll need to build a list (database/SQL) of all registry settings for each year and compare them.
Technically SW should "convert" last version settings to current version.
We all know how that goes already.

@Frederick_Law I am glad you mentioned the registry (btw with 2023 they moved the videocard workarounds that used to be inthe "performance" node outside the solidworks 20xx key...100s keys and not even documented afaik)

automating with api helped me to remake templates and check against the old reference file what was different and what I missed Instead of browse 100s of menus plus new settings to update our drafting standard.

I splitted the registry in 2 parts (system option and the rest of ui rrleted stuff) then pdm registry, edrawings and simulation.
still a mess a some reg is ver4 and some ver5 for compatibility reasons they cannot be merged yet as they use completely different encodings and our paths have a lot of double bytes characters also sw will process only the ver 4 if you want it to "clean up" your registry.

I am aware that sw save the whole registry block on the first run and everytime you close SW(even if some setting is applied real time in the registry from what I see from process monitor).


Not being able to export and compare those settings out of the box after all those years... then Isuspect there are a lot of "dead leaves" inside the reg tree or just a mess of settings added here and there like the pinned flag of command manager that should be exported under user interface or the user colors...or the cryptic keys that sounds like "workaround2019" or datumplane12345whatever, mixing code patches with real UI settIngs how nice of them!

I appreciate the effort you're taking here! I've considered doing something similar at various times, and I've never quite been burned badly enough to actually do it. But I've been close.

I did make one script that attempted to strip out the noise from the system options .sldreg exports, to make it easier to diff settings across systems. Working with the registry data may make more sense, but as @Frederick_Law indicated, some settings may not flush to the registry at run-time. Perhaps you can force this flush to the registry by doing dummy system options exports.

Another trick you can experiment with (which you're probably aware of) is starting Solidworks in "Rx Safe Mode" to bypass the system-options tools/settings. I don't know if you can export these "default options", but if so, that might be an easier reference point to collect than a fresh install.

I don't know how many people on here would be interested in contributing, but this is the sort of thing that might make sense as a github repo. I imagine you're developing powershell or python scripts to support this effort. Good luck!

One way is change every options in SW after first start so they're not default.
Might need to export after start, restart, change all options, restart, export.
Don't need to change any file name, path.
Change on/off, number, list.

Great work.

Another resource that I've used is Copy Drawing Option from Stefan Berlitz at http://swtools.cad.de/us_index.htm.

It's a bit old, but easily updated to grab all the various values.

Good luck with your quest!

doobes wrote: ↑Fri Feb 16, 2024 8:46 am Great work.

Another resource that I've used is Copy Drawing Option from Stefan Berlitz at http://swtools.cad.de/us_index.htm.

It's a bit old, but easily updated to grab all the various values.

Good luck with your quest!

thank you very much for the link.
I downloaded the excel data and it looks almost what I was trying to achieve.
In its current form is very dated, but I was able to update one sheet to 2023 variables and I am going to test in the office next week. The variables for each category are 2-3 times more than it used to be in 2008!
One more reason to keep track of them.

Like my approach the author of the excel thought about the best way to give a unique number to each setting, sorting them by SW version (roughly speaking the "year"). Obviously It makes no sense to strictly follow that order for a fresh start with SW2023, but I went throught the inconvenience of keep its order and add at the bottom the new variable from 2009 to 2023 so they are easier to comment if something does not work.

For a version up a comparison sheet could be build using a copy paste of enumerator lists from the SW help , putting their SW version year in the left column, then put together two years sort by enumerator name and filter the duplicates so only the new enumerators are added at the bottom.
I like the author approach to use a negative year number to disable the enumerators that got superseded, obsolete or for internal use only.

Frederick_Law wrote: ↑Tue Feb 13, 2024 9:04 am One way is change every options in SW after first start so they're not default.
Might need to export after start, restart, change all options, restart, export.
Don't need to change any file name, path.
Change on/off, number, list.

Yes lot of work, but it must be done for parts, assy and drawings separately as many options are hidden if the correspondent format is not open in SW when editing the options.
Document properties (at least half of it) could be exposed only by API as the registry is not involved there, and I cannot miss our setup when remaking the templates for a new SW version.

mp3-250 wrote: ↑Sun Feb 18, 2024 3:44 am thank you very much for the link.
I downloaded the excel data and it looks almost what I was trying to achieve.
In its current form is very dated, but I was able to update one sheet to 2023 variables and I am going to test in the office next week. The variables for each category are 2-3 times more than it used to be in 2008!
One more reason to keep track of them.

Like my approach the author of the excel thought about the best way to give a unique number to each setting, sorting them by SW version (roughly speaking the "year"). Obviously It makes no sense to strictly follow that order for a fresh start with SW2023, but I went throught the inconvenience of keep its order and add at the bottom the new variable from 2009 to 2023 so they are easier to comment if something does not work.

For a version up a comparison sheet could be build using a copy paste of enumerator lists from the SW help , putting their SW version year in the left column, then put together two years sort by enumerator name and filter the duplicates so only the new enumerators are added at the bottom.
I like the author approach to use a negative year number to disable the enumerators that got superseded, obsolete or for internal use only.

You are most welcome.

The downside to all this is the names of the settings are not easily searchable or indexible from within VBA, at least that I could find.

I wound up copying and pasting the various names from the API help and then literally going through those one by one. Not all of them are settable, but it's pretty straightforward to figure out.

Kind of a pain the first time, but after that not so difficult.

Getting this set up made creating new user system fairly trivial, at least after I got an IT person who was willing to do more than run the install daemon and accept all the defaults......

Unfortunately all this was done behind a very closed network enclave, so I don't have any of it to share.

Good luck

I leave it here as a warning to what happened to me today.
I was editing my templates from the dot files and some new setting (drawing transparency) was not applied to the drawing created with that template.

in the template file document properties the flag is OFF
same flag, in the file generated from the template is ON.
The advice to avoid editing slddot files is absolutely useful to avoid mistakes.


EDIT while the advice is still valid.
i discovered the transparency setting is actually bugged and has already a BR opened.

Do you have MS Access?
I can create table and database there and import excel file with registry settings.

No we do not have access.
I dumped all the settIngs in a txt format numbered and run a comparison.