Did you ever make the mistake of having Xternal References set to open read only and then have Don't Save Read Only Referenced Documents unchecked with multi-thousand part assembly or drawing. This is called READ ONLY HELL when you go to save the document. Wouldn't it be nice if there was a way to: a. Stop the save so the box could be checked b. Set some don't warn me check box c. Set the Don't Save option on the fly.
I've been considering writing a program to address this. Is this something a lot of users have trouble with? I'd like to hear from others.
I am rather surprised at the lack of response on this. Everyplace I have ever been, I have seen people trapped by this. Either people don't want to admit that they have gotten themselves into this trap on occasion or they learned their lesson and stay completely away from the problem. I think the problem has been mentioned in some of Matt's Rules of Thumb and perhaps some other places. My point is that when a trap like this exists in the software it needs to be addressed.
I think most users avoid the "Open referenced documents read only" switch, if they even know it exists. It's kind of a hassle needing to remember to reload parts with write access before making changes. I ran across a company that had the same question as Paul this past week, and the "Don't prompt to save changes to read only docs" switch saved them after spending a few days in read only hell. If you only make the mistake once and know how to fix it, it's not bad, but I don't think most users would know off the top of their heads what the fix was or even that there was a fix. On a kind of related issue, is anyone using the new collaboration techniques in SW 05? matt
The thing that really gets me is that we are prompted to save components that have not been changed.. if you just change a mate for a component, you are unecessarily prompted to save that component. I loathe this... it is so unnecessary, time consuming, and (frankly) scary because we can inadvertaently overwrite concurrent work on a part done by someone else. So yes, I share your pain
matt wrote: ....snip I haven't really looked at it much yet. Right now I am trying to get my fellow clones to consider actually collaborating. We have been using SW since '97 yet nobody has really considered the ability to work as a team to be something they wanted to do. So the skill set in place for this kind of thing is very minimal. I started some in house training to get everybody on the same page as far as file handling. Needless to say the read only switches are high on our priority list. I think you will find companies that have highly developed skill sets in this area and others that don't know it exists.
Ed, This has been a MAJOR grip of mine for years. Why would SW want to save something that has NOT changed. Just changing the configuration of a screw in an assembly causes SW to want to save the screw. The screw model DID NOT ACTUALLY CHANGE. Why would I want to re-save it. However, if there was an actual change to a part that may not be obvious (such a in-context feature referencing another part that did change), then I want SW to show me a printable list of which parts it wants to save! Otherwise, I may actually miss the fact that part23 changed because I made changes to part14. Currently, in an assembly with lots of in-context relations, I have to KNOW these references of the assembly inside-out in order to figure out all of the parts that actually changed by manually making a change to one part. This can be very difficult and can increase the potential for user error. A simple popup while saving the assembly saying: "hey buddy, since you changed part14, this caused changes in part23, part27, & part31. I am going to save them as well. OK?". Ok,ok. Maybe not in so many words....
pdm can solve these issues. i can't stress enough how valuable this software is. even if you can't afford pdmw, there are cheaper alternatives.
I have PDMworks and it doesn't solve this problem because this problem is with SW allowing users to get into a situation where either End Program or several thousand key/mouse strokes are the only answer. And this problem can still happen with PDMWorks installed although it shouldn't happen. Consider that PDMWorks will not easily allow the kind of collaboration that pure SW will in early stages of teaming/development over a network. Don't get me wrong though. PDM has a very important place, but it is, in my mind too much overhead in the very early stages of concept. Pure SW methods really shine there with a little discipline.
yes, you're right. pdm dosen't solve the problem per se, but it did for us. we no longer have the option set to open referenced docs as read-only. yes, you're right again. i don't agree with this at all (except for "PDM has a very important place,"). cheers, kb
In options there is a check box im external references that says Dont't prompt tp save read-only referenced documents (discard changes) It takes you out the hell and just saves the no read only parts and assys. When I used to do support someone called in and had the same question. Since then AFTER I found this option I have used it and it has save me and I know that customer sooo much time. Neil www.solidworktips.com
Neil, I think you are missing the point. I am well aware of the checkbox. In fact I mention it in my original post. That won't get you out once in. The experience of Read Only Hell is what happens when you don't check the box. And it is that experience that I am discussing. There has to be a better way of dealing with a setting in options that can get someone into such a problem. Hell is a place that is easy to get into and impossible to leave once there. Anyway I am glad you found the option.
I've never used that software "Press the freakin button", but I wonder if it would help when the window is already up? Mike
Actually you can just hold the ESC key down for a while. Or if you have rythm there is a certain sequence of keystokes that you do that will get your workmates attention. There are several tunes you can play. Come to think of it, isn't ESC supposed to escape us out of problems like this with a single stroke?
The pb with PTFB is that the text in the dialog window is not always the same, as it calls the name of the part. The esc key is the only way, or the _yes / _no key.