Save As

When I want to make a new part by modifying an existing part I use the save
as command and click "save as copy". The problem I have is sometimes I just
begin editing without realizing I have to close the existing part and open
up the new part. Is there any way I can change the program so that when I
use "save as" that the new part becomes the existing document?

TIA,
Roger

 

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

 

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.

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.

 

<<There is no technical reason why you should not be able to

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.

<<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.>>

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 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. >>

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.