This is a new one, and not good.
When opening a drawing that has corridor model xrefed in, the corridor section is not updating automatically.
If I reload the xref, it updates.
If I manually synchronize the alignment, it updates.
But just opening the drawing, it does not update.
I have even tried using the OTB tutorial drawings. Same problem.
Anybody else not having their cross sections update automatically?
Ok, if I create the section views in a drawing that contains an xref'd corridor, when I open the sections' drawing after having modified the corridor in its parent drawing, the corridor sections have not updated. XLOADCTL 0, 1 or 2.
If I Reload the Xref or synchronize my referenced alignment, the sections update.
Looks like a bug to me.
Please submit it to Almas. He is looking for examples.
Thanks
Fred
Easy workaround:
add these two lines to your acaddoc.lsp:
(vl-load-com)
(vl-cmdf "XREF" "R" "*")
That last part is hard to read. It's quote asterisk quote.
This forces an xref reload on opening any drawing.
When I tested it I had no data references except an alignment. I just had a drawing containing a corridor, which I xref'd in to another drawing and then made sections.
This defect has the potential to cause some incorrect output and that's a big deal, but it is easy to work around the issue using the lisp code I posted earlier.
I dont' think this is a "the sky is falling" problem.
I dont' think this is a "the sky is falling" problem.
I understand your perspective as you look at this as a software re-seller "please have no mind of these issues and continue to buy my software".
This is very critical knowledge for people to have who work in the Civil design shops. Incorrect ouput is an absolute business killer..
Again the statement from development, very astonishingly, states
"...we optimized the code to reduce the sync operation when open the drawing, which may results in some unexpected behavior when the object reference relationship is complicated. '
Stunning...
I understand your perspective as you look at this as a software re-seller "please have no mind of these issues and continue to buy my software".
That's an unfair characterization, sir. I provided a solution to the original post in this thread. When did I say "please have no mind....?" The solution is simple and takes ninety seconds to implement.
Now I will provide a solution to the re-synch issue:
Add these two lines to your acaddoc.lsp:
(vl-load-com)
(vl-cmdf "SYNCHRONIZEREFERENCES")
How is this issue causing the sky to fall if you can solve it so easily?
Oh, one last thing...please buy my software.
Best regards,
Tim
Why are you suggesting users re-engineer the software against the software developers' specific recent new programming intentions in this area of the software?
Do your research, starting with C3D 2013 the developers specifically and intentionally changed the data referencing code.
@fcernst wrote:Why are you suggesting users re-engineer the software ...
I'm not. I am just trying to offer a simple solution to those who want the synchronization process to happen upon opening of every drawing.
Have a great day, Fred.
Tim
Did you thoroughly and rigorously test this solution before suggesting this to users?
The current feedback I have from Support tells me Development has specifically targeted the synchronization process with new optimized code. They did not suggest overriding this behavior as you suggest.
There's a reason obviously they have not done, what you have done. Are you sure your procedure does not interfere with the new synchronization coding and other sequential loading of program support files at startup for 2013 and 2014?
Good grief, Fred. Autodesk has said there are instances that their new methodology does not work well with. Issuing the synchronizeallreferences forces the synchronization to occur. If you don't want to use it, don't. Someone may find Tim's snippets of code beneficial for their project(s). The only real thing it hurts, as far as I can tell, are the load times for the drawings which is what Autodesk was trying to improve.
FWIW, I have 2 projects that I MUST manually sync every drawing when opening. I have been using similar code when I know I will be working on those projects.
However, I would still like to have the underlying issue corrected so this workaround would not be needed.
No, I have no plans of using the suggestion at this point given the circumstances of the significant changes to the synchronization procedures in the official code that I have just recently become aware of. I have been advised to do otherwise from Support.
Q. Do you have sufficient and competent knowledge of the required sequential loading schedule of the program files (dll, exe, etc.) at Startup pertaining to the current optimized synchronization processes in 2013 and 2014?
Q. Can you state positively and affirmatively, regarding function of the optimized syncronization coding, and in consideration of the suggested Corridor Section production workflow that consists of consumer Section and source Corridor drawings, if the Data synchronization process should come 1) before the XREF synchronization process, or 2) after?
I didn't get very favorable results myself with the updated file. Has anyone else tested this?
BTW, Simply reloading the xref does nothing for me.
I was not in C3D when I copied the new file over. I opened the "base" file with the corridor in it and made a significant change, rebuilt and saved.
I opened the X-Section DWG that xreferences the base and data shortcuts the alignments. Upon opening the corridor looks correct but the QTO shading is still at the old location. I selected the alignment and "synchronized" now everything matches, but when trying to save I get the error message to recover. After recovering the drawing I get a mess:
Hi Bruce,
We have also seen Cross Sections not updating properly at times in 2014 SP2.
For comparison sake can I ask a few questions regarding worlkflow used to test the AeccRoadway.dbx file?
Were the EG, Corridor and Datum sampled sources only using Data references and no xref's of?
Was the Corridor xref'd using "Attachment" type?
Is Corridor set to "Rebuild Automatic"?
Hi Jay,
Sorry, meetings all morning.
The only data shortcuts I have are Centerline Alignment and the EG surface.
The Corridor, Datum, and FG are all cut/extracted through the XREF.
The Corridor in the base file is NOT set to "Rebuild Automatic".
All XREF's are in as "Attach".
Thanks
Not sure if it will help in this case but due to a number of problems with losing sampled sources and Total volume sec. view tables zeroing out we've been using this workflow:
Might be worth a try to see if it changes anything.
We do still occasionally have the issue of the corridors not updating through the xref (when users swear their following above workflow) but it's been random and hard to pin down any pattern. Thanks to @Lisa_Pohlmeyer for helping out with this workflow.