Unnecessary saving of assembly sub-components .. Why?

Simon, with all due respect, these are file properties. Not system properties, which are abstracted away in a separate file. If you believe our save file must contain “geometry only” at all costs otherwise our data structure is bad, then I don't know what to tell you. It is clear from what you’re saying, though, that you don’t have a good idea of what you’re looking at.

When you resize the Design Explorer, when you modify node expansion states, change File Properties values, etc. that is remembered between sessions on a file-by-file basis because that information is stored in the file properties, which are file specific, along with the geometry, which is file specific. That's why you don't open every file and the tree is collapsed; rather it is where you left it, how you left it, among many other things that operate similarly. Even if you send them to another person, or download it to a new machine. This is as normal as it is mundane.

With respect to files updating seemingly at random, or geometry changing

This should never happen. In almost no cases does it happen, and even less often in an unexplained way, once investigated.

Every time a file is saved it is versioned internally. Internal versioning is used, for example, to determine if a drawing should be updated or not – if the drawing’s idea of a part’s version is different than the part’s version, an update is prompted.

Like drawings, subassemblies also detect the versions of their constituents. If you have a subassembly that thinks a constituent part is v20, but once loaded the constituent part turns out to be v21, that subassembly is updated to reflect the new version context of its constituent. At this point, the subassembly has changed and it is now “dirty”, a term meaning that you will be prompted to save the changes to it. It has to be saved to know what version of the part it’s referencing.

In this way, it is possible that a part change you made a while ago in a seemingly unrelated place may have somehow worked its way, via the subassemblies and locations in models that it is in, into a model you’re viewing today and all of the sudden it’s asking you to save a subassembly. In nearly every case we see, it is because references are working their way up to ensure correct versioning.

Why individual files might prompt a save

In workspaces, there are obvious things that would prompt a save. Things like changing a part’s geometry. Changing its material. Changing its part data. There are other things that do this too, that may be less obvious. Anything that is file-related that is changed (except a few things) will prompt you for an update. Things like switching dimensions to Dual Dimensions, or modifying some visualization settings such as turning off Ambient Occlusion.

A handful of things do not, on their own, cause a file to prompt to be saved. Things like making the Design Explorer wider, changing Design Explorer node expansion states, or switching from Orthographic to Perspective. This class of items will get saved if the part is saved, but will not on their own prompt a save to take place.

To the original issue

The short answer is that without seeing your file we don’t know what happened. It could be something related to the API calls you’re using. Maybe it’s something you’re doing to actually dirty the part when it seems like it wouldn’t dirty it. Maybe it’s a bug. I don’t know because you have decided to write a novel on the forum in a derogatory, investigation-style tone instead of asking us. I do know that if we ever found a case that was truly unexplained of this behavior happening, or where geometry actually changed in an unexplained way, it would likely become the highest priority item of the team. We’ve had people ping us with this kind of question before, and after looking at what actually happened and explaining it, almost always the answer is “oh, yeah I did that”. Maybe yours is different – we need to check.

To the way in which you are choosing to engage with us

Simon, you have a very shoot first, don’t ask questions later approach to your “investigations”, assuming that you are always correct in your assertions about a codebase you have never seen and do not know the details of. I’m sure you are a fantastic developer, but in 20 years I have never seen any developer be as confident about a codebase they’ve never seen as you seem to be about ours. Take from that what you will. We do not, however, need SimonB65’s forum advice on how to run our teams, when to “sit down” with our team members, or how to “sort out” our “bad coding”. It’s getting really tiring to have to continue saying that. At some point soon I’m going to stop saying that.

Your post is very difficult to follow and doing so without model files is meaningless in any case.

However, the result of posts like this is that they are most often incorrect, and then we start to see follow on questions like this:

No, zoom and rotate do not trigger saves.

No. Drawings become disassociated typically when really fundamental changes have been made that completely remap the ACIS entity IDs. There might be another reason or two, but this has nothing to do with it.

No, it’s not.

This post is not adding value – it is causing confusion. It is to no one’s benefit.

So what can be done now?

A few things are obvious here. One, if Simon or others are having this issue they should send us files and we will investigate them. We’ll be happy to crack them open and see if there’s an issue. If there is, we’ll be on it.

Next, I think it is fair that even if some of the behavior is intended, it is obviously not transparent enough and perhaps there is room for the behavior to be changed to be more obvious or to operate in a different way or to give you more control. We can certainly evaluate those things. An obvious place to start is to more finely delineate which items that are saved on a per-file basis should result in an incrementing of the internal version number. That would probably go a long way to solving almost all of these issues.

I can say that millions of parts have been made in Alibre products over 22 years and this is not a rampant issue. For some people, clearly, there are perceived issues and perhaps real ones. Much of the behavior is probably for a good reason, but if you don't think it is you should work with us to figure out why this is happening for your workflow. That might result in either you learning something or in us taking different approaches to some things, both of which would be positive things.

Since this thread has little room for further progress given that we need more interaction / files and less conjecture, I'm going to close it for further comment. If someone would like to start a new thread to discuss specific about when they see these kinds of things, please do so as it would be helpful for everyone to see if there are any similarities to their own workflows.

 

To summarize Alibre's action items from this -

• We will evaluate the approach to internal version incrementation.
  • Some things you can change within a workspace today do cause version increases, and practically speaking that may be confusing and is probably unnecessary.
  • Some other things today cause version increases, and they should not.
    • This is the root cause of the issues described in this thread, I believe.
      
• The net result of this evaluation will be a set of changes that, when made, allow you to make "cosmetic" changes to files and to save them, but not increment the internal version number. This prevents save prompts and reprojections when you, as the user, feel like there is no reason for things to reproject or update things, because "all you did was open it and ____" (and then save).

This approach should alleviate the issue almost entirely and I think will be a big positive, assuming there are not other things at play such as a bug. While this thread did get a little out of control, the issues raised in general are good targets for action and I think we have a solid game plan to address them.