Skip to main content
J
JoshH1-Visitor
1-Visitor
July 15, 2014
Solved

Moving notes with Exploded View

  • July 15, 2014
  • 4 replies
  • 2314 views

Hi folks,

A colleague ran across this the other day and I'm really surprised that I have not see this before.

1. Create an explode-state.

2. Show it in a drawing.

3. Create a note with leader attached to an entity in that view

3. Add a component that increases the size of the view boundary

4. The note created in #3 moves

I understand the background of why it moves as the view boundary increases, but I find it completely unacceptable. I'm far from being a software programmer, but it seems easy enough to lock in the leader geometry and the attachment point on the entity. This would keep my note in the same place no matter what the view boundary does.

I submitted it to PTC-support, but their workaround seems only concerned with the origin location of the actual view and not notes associated with it.

Does anybody have a workaround for this?

Note: this is in Creo Elements/Pro 5.0 M170, but I believe it's still in all WF and Creo releases.

-Josh


This thread is inactive and closed by the PTC Community Management Team. If you would like to provide a reply and re-open this thread, please notify the moderator and reference the thread. You may also use "Start a topic" button to ask a new question. Please be sure to include what version of the PTC product you are using so another community member knowledgeable about your version may be able to assist.
Best answer by dschenken

Three things nail this down:

1) Set the view origin to something in the model that cannot change - such as an initial Coordinate system that precedes all other geometry.

2) Make the view a partial view - this fixes the view boundary so that notes and other items won't drift off. Just surround the model as-is, preferably bigger than minor changes will exceed.

3) Additional option: Create snap lines offset from geometry (not view boundary)

View origin is essentially a push-pin/thumbtack to nail the model to the paper. Leaving it set to center keeps the center of the geometry nailed down, but where that center is changes as the model changes and with it, the apparent location of the model on the paper.

I always wondered if the developers were willfully ignorant or thought they were doing a favor by driving 2D notation location relative to the view boundary. Of all things, nothing is more wastefully time consuming than trying to fix a drawing** when a minor change has been made and all the notations move. If I was prompted to "pick a location at a random fraction of some dimension of the view extents between the view origin and the point where you want the geometry to appear, but will later be moved upon re-scaling of the view extents" that would be a heads-up.

When I make a mark on something I expect the mark to be in exactly the same place later.

Instead the PTC developers for the drawing/detailing package seem to excel at creating dependency chains to do exactly what no one would seem to want to happen - moving markings on drawings.

This would make an excellent addition to a PTC Blog "Why we move the draft entities because the model extents change."

**or taking the steps required to avoid having to fix the drawing

4 replies

T
TomD.inPDX17-Peridot
17-Peridot
July 15, 2014

I had this same issue in a recent project. It is utterly insane that an otherwise perfectly good view should distort all the nomenclature in such a manner just because the view boundaries change.

If it is -that- important to have a fixed view reference location, maybe each view should have the option of utilizing one of the corners rather than a center based on the current geometry extent. Making view placement request a view center may also solve this. However, the current view origin dialog doesn't select vertices! Another huge oversight.

    D
    dschenken1-VisitorAnswer
    1-Visitor
    July 15, 2014

    Three things nail this down:

    1) Set the view origin to something in the model that cannot change - such as an initial Coordinate system that precedes all other geometry.

    2) Make the view a partial view - this fixes the view boundary so that notes and other items won't drift off. Just surround the model as-is, preferably bigger than minor changes will exceed.

    3) Additional option: Create snap lines offset from geometry (not view boundary)

    View origin is essentially a push-pin/thumbtack to nail the model to the paper. Leaving it set to center keeps the center of the geometry nailed down, but where that center is changes as the model changes and with it, the apparent location of the model on the paper.

    I always wondered if the developers were willfully ignorant or thought they were doing a favor by driving 2D notation location relative to the view boundary. Of all things, nothing is more wastefully time consuming than trying to fix a drawing** when a minor change has been made and all the notations move. If I was prompted to "pick a location at a random fraction of some dimension of the view extents between the view origin and the point where you want the geometry to appear, but will later be moved upon re-scaling of the view extents" that would be a heads-up.

    When I make a mark on something I expect the mark to be in exactly the same place later.

    Instead the PTC developers for the drawing/detailing package seem to excel at creating dependency chains to do exactly what no one would seem to want to happen - moving markings on drawings.

    This would make an excellent addition to a PTC Blog "Why we move the draft entities because the model extents change."

    **or taking the steps required to avoid having to fix the drawing

      J
      JoshH1-VisitorAuthor
      1-Visitor
      July 15, 2014

      Nice one David!!

      Actually, 1 and 2 did not work for me. #3 however, was the winner!

      I played with the snap lines a little before posing the question and somehow overlooked the boundary vs. geometry setting (might have something to do with the pre-Wildfire menu mangler interface).

      Now, the bad news is that orienting snap lines to geometry really su.. is disagreeable. If there are multiple notes, there will be snap lines all over the place and the user will probably spend quite a bit of time adjusting.

      To me, this workaround doesn't make up for the bad programming and PTC needs to fix it. I will continue harassing PTC (they are "researching the issue").

      J
      JoshH1-VisitorAuthor
      1-Visitor
      August 21, 2014

      Official response from PTC support is "This was resolved as working to specs."

      Absolute garbage...in my most humble opinion

      Terms & ConditionsCookie settingsAccessibility statement