Save As

Be careful - when you do a "Save as copy" the original file is still the active one. If you do a "Save as," the new one becomes the active one. This is because the copy one does just that - creates a copy - no references are changed. But if you do a "Save as," the references change and anything using it will be updated to use the new one.

WT

Also be aware the saveas part will replace the original part if its assembly is open.

Kman

Because of the fact that SolidWorks files are interdependent *, what you ask would not be strictly possible, except in the special case where no other open files referenced the part you are working on.

*eg: Assembly files require the information contained in part files, so whether or not You open the parts, SolidWorks has to "open" them in RAM. The only differences: it doesn't bother opening a window, and it doesn't need to worry about, say, hidden line removal and other display information.

Given that the command should behave consistently regardless of what other files might be open, the best approximation to what you ask would probably be to "close" the window of the original part file, and open the copied file in a new window, BUT ...(except in the special case in para 1) if you hadn't changed the name of the copied file, this would create an instant conflict. (If a file is open in memory, a different file with the same name cannot be opened)

Also this would annoy the hell out of users who use "Save As/Copy" to take a snapshot of a model to archive, as a disaster recovery/ Undo past last rebuild safety net, to send away for comment by others, to put in a folder of temporarily deranged parts, or whatever. In these cases, they want to carry on working with the original file. Lastly (when other open files referenced the original part) it would create some confusion in the user, because the original part would still be open in memory, along with the exact copy in a window. Edits to the original part via the assembly would not be reflected in the windowed part, perhaps leading to the illusion that they had not 'stuck'.

I understand your confusion and frustration, but the existing behaviour seems to me to be as simple as it could be, (hence can be understood in all likely contexts) while still offering a solution to all conceivable needs.

I tend to make a copy of the part (and assy/drawing if reqd) using windows explorer, then I can rename (for exanple "partxxx_iss2") then I open the assy/drawing and change the references. It's a litle more long winded but it removes all the confusion of the "save as" "save as copy" thing.

Kev

The fact that solidWorks files are interdependent has nothing to do with this.

Correct.

Right.

No, the best thing to do is leave the original where it is an open the copy in a new window. It is a MDI (multiple document interface) after all.

And *THAT* is the problem. This is one of the biggest flaws of SolidWorks. There is no technical reason why you should not be able to open 100 documents with the same name. Just as you can have 100 text documents with the same name open in Word, Excel, or any other MDI application, you *should* be able to do this in SW. Every file in the file system has a *unique* path to its location, regardless of its name. This is the information that SW should be using. The same flaw causes problems when users have network locations mapped to different drive letters.

As opposed to annoying the hell out of users who currently end up editing thev original instead of the copy. I don't see how annoying either group is acceptable.

This is analagous the the current situation where users get confused and think that they are changing the copy but are in fact changing the original.

I disagree. the simplest solution is to let the user choose which behavior he/she wants. A check box in the 'Save...As' dialog stating 'Open copy' is all that is required. Of course it will have to indicate an error if the document has the same name as a currently open document, but once again, that is a flaw in SW, not a technical problem.

Jim S.

No technical reason, unless you include the technicalities of how most humans identify files: by filename and by the look of the model. If you're one of those rare paragons who can faultlessly read, retain, (not to mention "compare and contrast") several entire paths simultaneously, this point will perhaps be lost on you.

I'm sorry Jim, perhaps agreeing to disagree will be as close as we can get on this one: I just don't see how having two identical models open at once could reduce confusion. If those models also have identical names, confusion is guaranteed.

At present, the result of doing a "Save As- Copy" is 100% predictable, and minimalistic. In terms of "what's open before" vs "what's open after", there is NO juggling by the software, either on screen or in RAM. Any juggling which may be needed is entirely under user control and at their discretion, on a case by case basis, and because there are so many scenarios (in terms of what to do about active models, references in RAM, etc etc), I for one want it under my control. Opening the copied file does not seem to me too great a price to pay, when that is what I want to do (which quite often it is).

I agree with the theory behind this suggestion, and in theory it lets me stick with what I have come to prefer. But, in practice, I can see this providing yet another instance where the user gets used to a certain behaviour only to get sandbagged when the default behaviour changes, unbeknownst, through upgrading, seat-sharing, or whatever. I would personally rather have something non-optimal and consistent, than something optimisable which was making such important behavioural changes behind the scenes.

I don't see how adding further options to a product simplifies it. SolidWorks is already a seething mass of options. The fact that they are so difficult to manage through SP and version changes is admittedly a different issue, but it does not help.

I shudder to think how many user-years get squandered when defaults for things like "Save e-Drawings data with documents" change (unannounced, in the background) from version to version, creating a 10x performance hit on saving.

You may justifiably argue that two wrongs do not make a right, and that specific limitations of the resource architecture and development team do not excuse software limitations. I would have to agree if you did.

My view, however, is that what is pragmatic trumps what would be ideal. We cannot change the development team. Unless we switch products, that is. I think almost everyone, even those who are continually frustrated, would agree that they have two strengths for every weakness.

But we can change what we wish for, and my view is that we should tailor our ambitions for the product, to the development team we have.

No need to retain such info. The title of the window serves quite well for such things. As do tooltips or any of the myriad of ways the full information about a file can be displayed to the user.

They aren't identical. And you don't open models. you open files. Two disticnt files *can't* be identical, due to the nature of the file system.

They can't have the same name, strictly speaking. The fact that SW chooses to consider them to have the same name is beside the point.

Predictability is not analagous to being intuitive.

Until the first time you've made significant changs to the wrong model.

No. All the juggling is done by the 'Save As' command. Is is your opinion that Save As should delete the old file?

So, you don't mind SW doing all sorts of juggling behind the scenes for Save...As, but for Save As Copy it is unacceptable?

Wow. I think I just read the description of Microsoft's wet dream for a user. Happy to have a suboptimal solution.

It doesn't. It makes the product more complex. If I wanted a 'simple' product, I would buy something at Office Depot. I expect power from a

4000 dollar piece of software.

Again, that has nothing to do with the product itself. That is a decision SW has made. Imagine of all those options were stored in a lovely text file that could be easily read/written by humans or custom software.

"Anybody who accepts mediocrity - in school, on the job, in life - is a person who compromises, and when the leader compromises, the whole organization compromises." --Charles Knight

Jim S.