Crazy Long Term Bug

[JSculley]

I stumbled across this little gem today:

1. Create a part
2. Right click the material in the feature tree
3. Select a material from the Favorites listed in the popout menu
4. Click Edit in the menu bar and look at the item in the undo list.

For me, it looks like this:

The Undo text is clearly wrong, since this is a part file and the last thing I did was apply a material. Clicking the item does the right thing and the material is changed back.

The really fun part is that the text changes based on what favorite material you choose. I have 8 favorites (from our company material database) and they map to these messages:

Code: Select all

6061-T6 ALUMINUM			Follow Sub-assembly Order
ALLOY 360 FREE MACHINING BRASS		Unable to compute value. Invalid entry.
303 STAINLESS STEEL			Unable to compute value. Cannot divide by zero.
A36 STEEL				Grid floor
ASTM A500 GRADE B			Local Trend
304 STAINLESS STEEL			History
ALLOY STEEL ASTM F835			Scenario
18-8 STAINLESS STEEL			Edit material

So, the last favorite shows the correct message, but that is just a coincidence. On a different machine with more favorites listed, the eighth favorite also results in the 'Edit material', and the prior 7 entries have the same text as well, even though the materials are different. Entries past 8 have other values. Nine is Set and ten is Minimize.

This nonsense is present in SW2022 SP4 (the latest I have installed) and goes all the way back to at least SW2017 SP5 (the earliest I have installed).

[Frederick_Law]

Getting text string in other part of memory.
Wonderful.

[bnemec]

Solid Edge had the same fun with tool tips on icons in some places, the text had nothing to do with the item. Makes me think of viewing the strings or other resources in a .dll file in Visual Studio object browser; get and old dll or the wrong dll and string #4 is not what you're expecting.

Really makes me wonder how many components of the software are farmed out to the lowest bidders scattered across the globe.

[jcapriotti]

Anyone have an SPR for it? I searched the knowledge base and didn't get anything. Tried "Material" and "Undo" together and got nothing on it that matches. Reporting it doesn't guarantee a fix, however if no one reports it, you can almost guarantee it will never be fixed.

[JSculley]

Anyone have an SPR for it? I searched the knowledge base and didn't get anything. Tried "Material" and "Undo" together and got nothing on it that matches. Reporting it doesn't guarantee a fix, however if no one reports it, you can almost guarantee it will never be fixed.

I have an open ticket for an issue that I was working on when I found this problem. I'll mention it to my VAR once we resolve the initial issue.

[bnemec]

I have an open ticket for an issue that I was working on when I found this problem. I'll mention it to my VAR once we resolve the initial issue.

Interesting. When you recurse down the SW issue tree you just push them on a separate stack for later instead of getting bogged down trying to resolve them as you drill down? I'm doing this all wrong!

[JSculley]

The newer issue has more angular momentum so it can sit for a bit.

[bnemec]

The newer issue has more angular momentum so it can sit for a bit.
image.png

Ah, so not a stack, it's a queue?

[JSculley]

Here's another tangentially related bit of strangeness. The Material dialog has a Config... button that lets you specify where the material should be applied: this config, all configs, specific configs. This setting is seemingly global. For example, if you edit the material in one part document, set it to all configs and then switch to another part document and edit the material, the setting will still be all configs. If you change it to this config and then go back to the original part and edit the material, the setting will have changed to this config. So the setting seems to be tied to the material dialog itself, and not associated with the document.

The strangeness happens when you start changing materials of components from an assembly. I created two part files ABC and DEF with configurations A,B,C and D,E,F respectively. In ABC I changed the material and used the this config setting to change the material in each config like this:

A - Pine (the active config)
B - Rubber
C- Corrugated Paper

Then I opened DEF and changed its material and used the all configs option so it now looked like this:

D - 6061 Aluminum (the active config)
E - 6061 Aluminum
F - 6061 Aluminum

I placed these parts into an assembly using the active config for each. I selected ABC and DEF in the feature tree and from the Edit menu, selected Appearance--->Material

The Config... is greyed out at this point, since there are multiple parts selected. I selected AISI 304 and clicked Apply.

The question then is what settings will be used to apply the material? The consistent approach would be to use the last setting that was used in the dialog and all configs will end up with AISI 304 for the material. After all that's how it works any other time. The results I get are this:

A - AISI 304
B - Rubber
C- Corrugated Paper

D - AISI 304
E - AISI 304
F - AISI 304

At first glance, it seems as though SOLIDWORKS has secretly stored information about the material dialog settings on a per document basis and used that to apply the material. I can sort of see the idea there but it seems inconsistent to me.

I did the experiment a second time but I changed things so that both part documents had the material config info set to all configs. So the parts start out like this:

A - Pine (the active config)
B - Pine
C- Pine

D - 6061 Aluminum (the active config)
E - 6061 Aluminum
F - 6061 Aluminum

If SOLIDWORKS is storing settings per document, I would expect that changing the material of both components from the assembly would result in all configs of both parts being AISI 304. Instead, I get this:

A - AISI 304
B - Rubber
C- Corrugated Paper

D - AISI 304
E - AISI 304
F - AISI 304

Exactly the same as the original test. So much for the 'settings per document' theory. Now we get into the weeds. I repeat the second test but reverse the order in which I select the items in the feature tree, selecting DEF and then ABC. The results are:

A - AISI 304
B - AISI 304
C- AISI 304

D - AISI 304
E - 6061 Aluminum
F - 6061 Aluminum

Yep. That's right. The application of materials to multiple components in an assembly is dependent on the order of selection in the feature tree.

[bnemec]

Here's another tangentially related bit of strangeness. The Material dialog has a Config... button that lets you specify where the material should be applied: this config, all configs, specific configs. This setting is seemingly global. For example, if you edit the material in one part document, set it to all configs and then switch to another part document and edit the material, the setting will still be all configs. If you change it to this config and then go back to the original part and edit the material, the setting will have changed to this config. So the setting seems to be tied to the material dialog itself, and not associated with the document.

The strangeness happens when you start changing materials of components from an assembly. I created two part files ABC and DEF with configurations A,B,C and D,E,F respectively. In ABC I changed the material and used the this config setting to change the material in each config like this:

A - Pine (the active config)
B - Rubber
C- Corrugated Paper

Then I opened DEF and changed its material and used the all configs option so it now looked like this:

D - 6061 Aluminum (the active config)
E - 6061 Aluminum
F - 6061 Aluminum

I placed these parts into an assembly using the active config for each. I selected ABC and DEF in the feature tree and from the Edit menu, selected Appearance--->Material

The Config... is greyed out at this point, since there are multiple parts selected. I selected AISI 304 and clicked Apply.

The question then is what settings will be used to apply the material? The consistent approach would be to use the last setting that was used in the dialog and all configs will end up with AISI 304 for the material. After all that's how it works any other time. The results I get are this:

A - AISI 304
B - Rubber
C- Corrugated Paper

D - AISI 304
E - AISI 304
F - AISI 304

At first glance, it seems as though SOLIDWORKS has secretly stored information about the material dialog settings on a per document basis and used that to apply the material. I can sort of see the idea there but it seems inconsistent to me.

I did the experiment a second time but I changed things so that both part documents had the material config info set to all configs. So the parts start out like this:

A - Pine (the active config)
B - Pine
C- Pine

D - 6061 Aluminum (the active config)
E - 6061 Aluminum
F - 6061 Aluminum

If SOLIDWORKS is storing settings per document, I would expect that changing the material of both components from the assembly would result in all configs of both parts being AISI 304. Instead, I get this:

A - AISI 304
B - Rubber
C- Corrugated Paper

D - AISI 304
E - AISI 304
F - AISI 304

Exactly the same as the original test. So much for the 'settings per document' theory. Now we get into the weeds. I repeat the second test but reverse the order in which I select the items in the feature tree, selecting DEF and then ABC. The results are:

A - AISI 304
B - AISI 304
C- AISI 304

D - AISI 304
E - 6061 Aluminum
F - 6061 Aluminum

Yep. That's right. The application of materials to multiple components in an assembly is dependent on the order of selection in the feature tree.

Isn't that normal behavior of the "which config to apply this to" tool? It feels the same as when making other changes in part and assembly. It's not tied to the document; it feels like it's just the last time that which config option picker was open.

Because of this issue and several others, we've done an about face on configs, they just introduce too many places for things to go wrong in our environment. There was a lot of uses of configs to start with but already have caused too many problems and the fix/prevention/mitigation path just isn't worth it.

Same thing for editing parts from the Assembly, it's usually dangerous unless the user really understands how the software is intended to function. Even in SE people would mess up a lot of other stuff unwittingly when editing parts from assembly; that was one reason to have some kind of file management, to lock files so they weren't saving changes to files that they didn't even understand they were doing. I would avoid editing parts from upper-level assemblies, both in SE and SW. Especially now in SW with its terrible selection behavior (at least for when we're doing) compared to SE.

[mattpeneguy]

I stumbled across this little gem today:

1. Create a part
2. Right click the material in the feature tree
3. Select a material from the Favorites listed in the popout menu
4. Click Edit in the menu bar and look at the item in the undo list.

For me, it looks like this:

image.png

The Undo text is clearly wrong, since this is a part file and the last thing I did was apply a material. Clicking the item does the right thing and the material is changed back.

The really fun part is that the text changes based on what favorite material you choose. I have 8 favorites (from our company material database) and they map to these messages:

Code: Select all

6061-T6 ALUMINUM			Follow Sub-assembly Order
ALLOY 360 FREE MACHINING BRASS		Unable to compute value. Invalid entry.
303 STAINLESS STEEL			Unable to compute value. Cannot divide by zero.
A36 STEEL				Grid floor
ASTM A500 GRADE B			Local Trend
304 STAINLESS STEEL			History
ALLOY STEEL ASTM F835			Scenario
18-8 STAINLESS STEEL			Edit material

So, the last favorite shows the correct message, but that is just a coincidence. On a different machine with more favorites listed, the eighth favorite also results in the 'Edit material', and the prior 7 entries have the same text as well, even though the materials are different. Entries past 8 have other values. Nine is Set and ten is Minimize.

This nonsense is present in SW2022 SP4 (the latest I have installed) and goes all the way back to at least SW2017 SP5 (the earliest I have installed).

If you'd quit making mistakes requiring you to undo the selection this wouldn't be a problem...