Views not updating on sheets

[Anonymous]

When I drag a named view onto a sheet none of the layer settings come through from the view file. After the viewport is on the sheet and I change what layers are displayed, the changes do not come through to the sheet.

I have tried the "Update Layers" and "Save layer snapshot" option on and off option and gotten the same result.

Here is Autodesk's response:
-----------------------------------------
I had a chance to look into this issue and found that I was able to reproduce the problem on my end. Further research found that this issue had already been logged with our development staff scheduled to be addressed in future releases. I will add your name to the case logged with development.

Currently I think the best workaround for views not updating on a sheet is simply to delete the view from the sheet and reinsert it after changing the layers in the view and saving them.
-----------------------------------------

This problem is unacceptable. I cannot have users re-dragging named views down to the sheets every time a layer setting has changed in the view file. For one, the position of the named view on the sheets would never be the same; making the project inconsistent. Two, that’s a serious time waster. This is an elementary problem in a very mature product. How are other firms addressing this issue?

Our layers change on a daily basis depending on what the engineer/designer needs to have displayed for him/her to design a project. They should not have to worry if the correct layers are on/off on the plotting sheets.

Does anyone here have any insight????????

[Anonymous]

I went back to using code I'd written 10 years ago, to change XRef's layers
to what we defined in an .ini file for the project.

In fact, it is likely my issue that your name got tagged on to. ;^)

--
R. Robert Bell


wrote in message news:5415840@discussion.autodesk.com...
When I drag a named view onto a sheet none of the layer settings come
through from the view file. After the viewport is on the sheet and I change
what layers are displayed, the changes do not come through to the sheet.

I have tried the "Update Layers" and "Save layer snapshot" option on and off
option and gotten the same result.

Here is Autodesk's response:
-----------------------------------------
I had a chance to look into this issue and found that I was able to
reproduce the problem on my end. Further research found that this issue had
already been logged with our development staff scheduled to be addressed in
future releases. I will add your name to the case logged with development.

Currently I think the best workaround for views not updating on a sheet is
simply to delete the view from the sheet and reinsert it after changing the
layers in the view and saving them.
-----------------------------------------

This problem is unacceptable. I cannot have users re-dragging named views
down to the sheets every time a layer setting has changed in the view file.
For one, the position of the named view on the sheets would never be the
same; making the project inconsistent. Two, that's a serious time waster.
This is an elementary problem in a very mature product. How are other firms
addressing this issue?

Our layers change on a daily basis depending on what the engineer/designer
needs to have displayed for him/her to design a project. They should not
have to worry if the correct layers are on/off on the plotting sheets.

Does anyone here have any insight????????

[Anonymous]

The advantage of having layers fixed in the plot sheet is that inadvertent changes to the
view layers do not adversely affect the plot. If you want the view layers to be governed
by the view drawing, then just setting visretain to 0 should solve your problem. If that
doesn't work, then vplayer thaw * on the affected viewports. Then control is at the view
drawing rather than on the sheet. But what if an engineer, trying to simplify his life
forgets to turn on an important layer before he saves it?

I have a lisp that temporarily sets visretain to 0, reloads the xref, and then resets
visretain to 1 in the sheet file. Perhaps something like that would help.

Good luck.

wrote in message news:5415840@discussion.autodesk.com...
When I drag a named view onto a sheet none of the layer settings come through from the
view file. After the viewport is on the sheet and I change what layers are displayed, the
changes do not come through to the sheet.

I have tried the "Update Layers" and "Save layer snapshot" option on and off option and
gotten the same result.

Here is Autodesk's response:
-----------------------------------------
I had a chance to look into this issue and found that I was able to reproduce the problem
on my end. Further research found that this issue had already been logged with our
development staff scheduled to be addressed in future releases. I will add your name to
the case logged with development.

Currently I think the best workaround for views not updating on a sheet is simply to
delete the view from the sheet and reinsert it after changing the layers in the view and
saving them.
-----------------------------------------

This problem is unacceptable. I cannot have users re-dragging named views down to the
sheets every time a layer setting has changed in the view file. For one, the position of
the named view on the sheets would never be the same; making the project inconsistent.
Two, that's a serious time waster. This is an elementary problem in a very mature
product. How are other firms addressing this issue?

Our layers change on a daily basis depending on what the engineer/designer needs to have
displayed for him/her to design a project. They should not have to worry if the correct
layers are on/off on the plotting sheets.

Does anyone here have any insight????????

[Anonymous]

Doug - If the layers are fixed in the plot sheets, views, & constructs that is three places an engineer has to modify layers for a file - thats just not acceptable. I have tried setting visretain on the sheet to 0 with no luck.

I could not get vplayer thaw to work. Can you go through the exact steps to using vplayer thaw * to make the sheet control at the view drawing?

Thank you very much!

[Anonymous]

Doug, I don't believe that works. Doesn't the sheet get the layer settings
from the constructs in that scenario?

And if the architectural drawings are out-of-house, and constructs, they
will not display as needed to get a correct plot (or display).

--
R. Robert Bell


"Doug Broad" wrote in message
news:5415916@discussion.autodesk.com...
The advantage of having layers fixed in the plot sheet is that inadvertent
changes to the
view layers do not adversely affect the plot. If you want the view layers
to be governed
by the view drawing, then just setting visretain to 0 should solve your
problem. If that
doesn't work, then vplayer thaw * on the affected viewports. Then control
is at the view
drawing rather than on the sheet. But what if an engineer, trying to
simplify his life
forgets to turn on an important layer before he saves it?

I have a lisp that temporarily sets visretain to 0, reloads the xref, and
then resets
visretain to 1 in the sheet file. Perhaps something like that would help.

[Anonymous]

Our current work-around is to freeze layers/turn off xrefs that are not needed in the model space of each sheet. We will use the viewfiles only to cut named views for the sheets.

I would like to have the views file be the control for sheets that vp it. This is the way we were explained ABS in the beginning and I am finding out now that just is not true. You have to manipulate the layers on the sheets.

Thanks for everyones responses!

[Anonymous]

Hi Robert,
You're right. Unfortunately, each xref's layers are brought into the target directly from
the most deeply nested xref. It shouldn't be difficult to clone the layer settings from
the least nested xref (the view) though, using objectdbx. Probably an hour of coding.
Sorry we didn't have more time to talk at AU. Perhaps in the future.

Regards,
Doug

"R. Robert Bell" wrote in message
news:5416542@discussion.autodesk.com...
Doug, I don't believe that works. Doesn't the sheet get the layer settings
from the constructs in that scenario?

And if the architectural drawings are out-of-house, and constructs, they
will not display as needed to get a correct plot (or display).

--
R. Robert Bell


"Doug Broad" wrote in message
news:5415916@discussion.autodesk.com...
The advantage of having layers fixed in the plot sheet is that inadvertent
changes to the
view layers do not adversely affect the plot. If you want the view layers
to be governed
by the view drawing, then just setting visretain to 0 should solve your
problem. If that
doesn't work, then vplayer thaw * on the affected viewports. Then control
is at the view
drawing rather than on the sheet. But what if an engineer, trying to
simplify his life
forgets to turn on an important layer before he saves it?

I have a lisp that temporarily sets visretain to 0, reloads the xref, and
then resets
visretain to 1 in the sheet file. Perhaps something like that would help.

[Anonymous]

Agreed. I've just had far greater issues to deal with, and it irks me to
have to write the code to fix the obvious problem.

However, it is sort of self-defeating to try it. Here is why:

Let's say I have these constructs: Arch1 (client-provided), HVAC1, and
Power1.

So I open HVAC1, and drop Arch1 in there. It comes in as an overlay, so I
need to change the layers for Arch1 to display grey, or change the Display
Rep for it to be screened (oh, wait, what if I need RClg to plot
differently?).

I have to do the same thing for Power1. Rinse and repeat for the dozens of
plan drawings in a decent project.

Now, let's get to View drawings. I have to do the same thing I did for the
constructs. Blech. This seems really familiar.

Now, let's get to the Sheet drawings. Yet more of the same.

So the code *could* see if the current drawing is a construct, see if XRefs
are there that are also constructs (overlays), screen them. Heaven forbid if
we want to display/plot certain layers/constructs differently than the rest
of the architectural stuff (think RClgs in HVAC, hmm). Then the same code
needs to, at the View level, now work with attached XRefs from the construct
layer (doable). Then we can finally get to the Sheet drawings, where we can
have the code run as you envision.

--
R. Robert Bell


"Doug Broad" wrote in message
news:5417054@discussion.autodesk.com...
Hi Robert,
You're right. Unfortunately, each xref's layers are brought into the target
directly from
the most deeply nested xref. It shouldn't be difficult to clone the layer
settings from
the least nested xref (the view) though, using objectdbx. Probably an hour
of coding.
Sorry we didn't have more time to talk at AU. Perhaps in the future.

Regards,
Doug

[Anonymous]

We have yet to fully implement ABS and haven't yet started using the Project Navigator/elements/constructs/views. After reading this post I wonder: is it worth it?

[Anonymous]

As far as turning layers to the correct colors & linestyles I do that in each arch background (that way they have no choice but to look right). Its the layers being turned off/on that has been such a headache.

[Anonymous]

Of course it is. The problems discussed here are common to any nested xref
system. The Project Navigator has many benefits over manually xreffing.
Read about it and decide for yourself.

wrote in message news:5417499@discussion.autodesk.com...
We have yet to fully implement ABS and haven't yet started using the Project
Navigator/elements/constructs/views. After reading this post I wonder: is
it worth it?

[Anonymous]

Doug,

The problems are *not* common to _any_ nested XRef system.

In vanilla-land, if I XRef the arch drawing into a "holding" drawing, and
change the XRef's properties in the holding drawing, then whenever I attach
the _holding_ drawing, the arch XRef displays as I set in the holding
drawing.

Due to the dynamic drag-and-drop constructed XRefs approach of the PN, this
cannot happen. So code is the only way to "correct" the issue.

--
R. Robert Bell


"Doug Broad" wrote in message
news:5417877@discussion.autodesk.com...
Of course it is. The problems discussed here are common to any nested xref
system. The Project Navigator has many benefits over manually xreffing.
Read about it and decide for yourself.

wrote in message news:5417499@discussion.autodesk.com...
We have yet to fully implement ABS and haven't yet started using the Project
Navigator/elements/constructs/views. After reading this post I wonder: is
it worth it?

[Anonymous]

I do like working with PN. Once I got past the layer issue with my own code,
things got better.

--
R. Robert Bell


wrote in message news:5417499@discussion.autodesk.com...
We have yet to fully implement ABS and haven't yet started using the Project
Navigator/elements/constructs/views. After reading this post I wonder: is
it worth it?

[Anonymous]

Ah, but that approach requires manually working on the drawing every time it
comes in. My approach allows us to simply drop the update in place, and all
the other drawings are updated when opened. No effort on our part, aside
from initial .ini file setup.

--
R. Robert Bell


wrote in message news:5417628@discussion.autodesk.com...
As far as turning layers to the correct colors & linestyles I do that in
each arch background (that way they have no choice but to look right). Its
the layers being turned off/on that has been such a headache.

[Anonymous]

In my environment, it depends on what format I am getting from the arch:
ACAD & Revit exports - It is a manual step every time you get updates but you can speed this process up drastically using exported layer states.

Now when we recieve ADT files, the layering will be handled automatically by our display representations that I have customized.

If only all of our clients used ADT the CAD Coordination time on each of our projects would drop.............

What are doing with .ini files to get around the manual step? What happens when the arch adds new layers that you have not changed the colors/linestyles for? Do you have to go and edit your custom .ini file?

[Anonymous]

Our clients, for the most part, use an NCS-style layer scheme. So our .ini
file uses mostly wildcards to set the layer properties as we desire.

We can also, based on the .ini group we put a filter under, display/plot the
layer differently depending on our drawing's discipline. E.g. the [Plumbing]
section lists layers that will plot in medium weight for our plumbing
drawings, but the rest of the disciplines plot those layers screened.

--
R. Robert Bell


wrote in message news:5417960@discussion.autodesk.com...
In my environment, it depends on what format I am getting from the arch:
ACAD & Revit exports - It is a manual step every time you get updates but
you can speed this process up drastically using exported layer states.

Now when we recieve ADT files, the layering will be handled automatically by
our display representations that I have customized.

If only all of our clients used ADT the CAD Coordination time on each of our
projects would drop.............

What are doing with .ini files to get around the manual step? What happens
when the arch adds new layers that you have not changed the
colors/linestyles for? Do you have to go and edit your custom .ini file?

[Anonymous]

Unless I am misunderstanding, it *is* common if you are going to use overlay
xrefs for one task and attached xrefs for the others. I believe you can
also choose to override the overlay setting to attachment manually in the
construct before making the view. I personally don't worry about the layers
of overlaid xrefs at the construct level. Their only purpose is to provide
a temporary background. The screened display reps and express tools layoff
command work pretty well to get to where I can start the work. The only
thing I use constructs for is to place the ADT/ABS objects, which have 3
dimensional capabilities.

Its in the view that I worry about layering and its in the view that the
constructs are attached vs overlaid. My workflow is to get almost done with
the view before placing it on the sheets. That keeps these layering issues
from becoming big problems. I have also deleted views from sheets and
reloaded them via the PN and that is not a big problem either. I just wish
that the callout fields would unbreak themselves.



"R. Robert Bell" wrote in message
news:5417935@discussion.autodesk.com...
Doug,

The problems are *not* common to _any_ nested XRef system.

In vanilla-land, if I XRef the arch drawing into a "holding" drawing, and
change the XRef's properties in the holding drawing, then whenever I attach
the _holding_ drawing, the arch XRef displays as I set in the holding
drawing.

Due to the dynamic drag-and-drop constructed XRefs approach of the PN, this
cannot happen. So code is the only way to "correct" the issue.

--
R. Robert Bell


"Doug Broad" wrote in message
news:5417877@discussion.autodesk.com...
Of course it is. The problems discussed here are common to any nested xref
system. The Project Navigator has many benefits over manually xreffing.
Read about it and decide for yourself.

wrote in message news:5417499@discussion.autodesk.com...
We have yet to fully implement ABS and haven't yet started using the Project
Navigator/elements/constructs/views. After reading this post I wonder: is
it worth it?

[Anonymous]

Plus in our case, different trades often want different arch layers set to
different colors (and thus plot weights).

-Chris

wrote in message news:5417628@discussion.autodesk.com...
As far as turning layers to the correct colors & linestyles I do that in
each arch background (that way they have no choice but to look right). Its
the layers being turned off/on that has been such a headache.

[Anonymous]

All disciplines here use the same colors for backgrounds. I could see where your situation would be even more to keep up with.