.NET API functions to interrogated Civil 3D drawings for possible data shortcut dependencies

[Wish List System]

Summary: Would like to be able to programmatically find the dependent drawings (name and path) that are referenced in the active drawing's data shortcuts.

Description: Would like to be able to programmatically find the dependent drawings (name and path) that are referenced in the active drawing's data shortcuts.

Product and Feature: AutoCAD Civil 3D - API

Submitted By: Bruce Dana on 08/07/2014

[BlackBox]

Summary: Would like to be able to programmatically find the dependent drawings (name and path) that are referenced in the active drawing's data shortcuts.

Description: Would like to be able to programmatically find the dependent drawings (name and path) that are referenced in the active drawing's data shortcuts.

Product and Feature: AutoCAD Civil 3D - API

Submitted By: Bruce Dana on 08/07/2014

Hi Bruce, glad to see you here at AUGI!

Is your Civil 3D development team getting stuck again? Sheesh. I stopped beta testing the FDOT C3D [2011-2014] State Kit when my review comments for application startup alone grew to +/- 13 pages of pointing out fundamental no-nos.


In any event, to your wish....

Given a valid selection of an AeccDb* Object within the MdiActiveDocument, where IsReferenceObject == true, one can conditionally search the appropriate ..\_shortcuts\ folder for the DREF's XML file.



As an example:

Select an AeccDbSurfaceTin Object, and get the Name Property string. For the purposes of this example, let's name it "EG01." As this is a Surface, search ..\_shortcuts\surfaces\ folder for EG01*.xml file. There will be one, in the format of:

<DataReferenceName>_<GUID>.xml

... For each unique data reference. See this screenshot:





When you open said XmlDocument, you can extract the information you seek from one of a few different locations.

First is Shortcuts\Shortcut XmlNode, specifically the "name" XmlAttribute's value, in the format of:

<FullFilePath>\<DrawingName>.dwg:<DataReferenceName>

Second, is Shortcuts\Shortcut\DwgRelPath XmlNode, specifically the "path" XmlAttribute's value, in the format of:

<RelativeFilePath>\<DrawingName>.dwg

Third option within the same XmlDocument, is Shortcuts\Shortcut\Criteria\File XmlNode, specifically, the "name" XmlAttribute's value, in the format of:

<FullFilePath>\<DrawingName>.dwg

See this screenshot:





Ribbing your development team aside, I sincerely hope this helps.

Cheers

[BlackBox]

...

As an example:

Select an AeccDbSurfaceTin Object, and get the Name Property string. For the purposes of this example, let's name it "EG01." As this is a Surface, search ..\_shortcuts\surfaces\ folder for EG01*.xml file. There will be one, in the format of:

<DataReferenceName>_<GUID>.xml

... For each unique data reference. See this screenshot:



...

While I did describe the specified task here, I should have pointed out the implicit aspect, in how to consistently identify the location of the ..\_shortcuts\ folder... Without iteratively getting the parent directory, checking for sub-directories, etc. throughout an entire DWGPREFIX directory tree depending on how your projects are setup (here's an old FDOT C3D 2012 project directory, which is ..\..\_shortcuts\ from DWGPREFIX [assuming drawing not located within ..\eng_data\ sub-folder]):





In my 'WorkingFolderHere' plug-in, I've included the following Property:

//...

        public static string ShortcutFoldersXmlPath
        {
            get
            {
                string path = acApp.GetSystemVariable("ROAMABLEROOTPREFIX").ToString()
                    + "Project Management\\ShortcutFolders.xml";

                if (!File.Exists(path))
                    path = "";

                return path;
            }
        }

//...

... Which I can then open as XmlDocument in order to iterate the WorkingFolders/WorkingFolder XmlNode(s), checking for "current" XmlAttribute value != "0", which identifies the 'active' working folder in C3D, and the "path" XmlAttribute for same XmlNode yields the working folder's actual file path.

Concatenated as:

string shortcutsPath = xmlNode.Attributes["path"].Value + "\_shortcuts\";

... Yields the implicitly required ..\_shortcuts\ file path for the steps above, from which you can then obviously conditionally navigate to the desired sub-folder(s).

Cheers

[BlackBox]

*Bump*



Just following up... Did any of this help with your request, Bruce?

Cheers

[Jeff_M]

BB, I'll respond because I've also wanted this in the API for some time. If you open a drawing with Dref's, that dwg has not been associated with a project, and the Working folder is not correct for this dwg's project. The drawing still loads the shortcuts fine, you can still use the Open Source Drawing, but your method will fail (I think, haven't tested it) since the Working Folder is pointing somewhere else.

[BlackBox]

BB, I'll respond because I've also wanted this in the API for some time. If you open a drawing with Dref's, that dwg has not been associated with a project, and the Working folder is not correct for this dwg's project. The drawing still loads the shortcuts fine, you can still use the Open Source Drawing, but your method will fail (I think, haven't tested it) since the Working Folder is pointing somewhere else.

Admittedly, I assume that a drawing with DREF has been associated with a project.

I'd have to interrogate DREF further to wrap my brain around how/why you'd do this without such an association, as that's just not common for my workflows.

Does that happen to you often (drawings with DREF and no project association)?

Further, how does adding a DREF _not_ automagically associate project to drawing (@Autodesk)?!?

Cheers

[Jeff_M]

A quick one on how this can occur. Say I have a phased project, the topo dwg with Surface for the entire site is in the first phase. Each phase has it's own project, and will likely be in separate years (our working folders get set to the year). Each phase's drawings are associated to it's own project. However, by changing the working folder and project folder to the Phase 1 project, I can then Dref the original Surface. I then reset the working/project folder to the current one. So now my drawings are using Dref's from 2 projects without any problems...until the source drawing cannot be located.

Now, this isn't how things normally get done. It's just an example of how one could...

[BlackBox]

Now, this isn't how things normally get done. It's just an example of how one could...

Fair enough, and thanks for the effort to clarify this , albeit easily avoidable, potentiality.

I have deadlines tomorrow, and early next week, but should have several days thereafter for ancillary tasks; I'll see if I can't work this particular test in during the latter.

Cheers

[ralstogj]

Black Box

I have been trying to figure out a tool to visually map xrefs and drefs within a project file. I have figured out a process for the xref's using some old lisp code that you posted and now wish to do the same for the dref's.

I have explained what I have done on my blog a bit here

http://c3dxtreme.blogspot.com/2018/1...l-network.html

and also in this forum post a bit more.

https://forums.autodesk.com/t5/visua...8163801/page/2

What it be possible to dump out a text file of the dref's using .net similar to the lisp code does for xref's? or do you know of a tool that does this?

Once I have that data it is reasonably straight forward to chart the project in Nodexl.

Regards

Justin Ralston

[BlackBox]

Hi Justin -

Welcome to AUGI; I'm glad you found the BatchFindXref code useful.


You mean something like this old post?

http://forums.augi.com/showthread.ph...88#post1299188

For those not already familiar with Civil 3D's Data Shortcuts workflow....

<snip>

Rather than....

Iterating each GetAlignmentIds(), GetPipeNetworkIds(), and GetSurfaceIds(), etc., checking for IsReferenceObject == true, get the CivilDocument.Settings.AssociateShortcutProjectId string, then open <RoamableRootPrefix>\\Project Management\\ShortcutFolders.xml as XmlDocument, to iterate WorkingFolder\ShortcutFolder XmlNodes, filtering for "uuid" XmlAttribute's string value that == CivilDocument.Settings.AssociateShortcutProjectId string, to get "path" XmlAttribute's string value, then iterate the XML files found at "path" XmlAttribute's string value + \\_shortcuts\\<AeccObjectReferenceType>\\ filtering for <FileName>.Contains(<DataReferenceName>) (or WCMATCH same?), to then open THAT as XmlDocument, reading ProjectInfo\Shortcuts\Shortcut\Criteria\File XmlNode's "name" XmlAttribute's string value, to get source\parent model drawing... Sheesh, I'm winded just typing all of this malarchy, and we haven't even updated the Data References yet! Haha

... Isn't there a simpler way of going about this entire procedure?

The Working Folder history is stored in <RoamableRootPrefix>, but if that is just pointing to the location of ..\_shortcuts\ folder, and the CivilDocument.Settings contain the Associated Project ID, then why not just point directly to the same ..\_shortcuts\ folder in the first place? (or add exposed Properties to CivilDocument.Settings that expedite even this!?)

There, in the ..\_shortcuts\ folder, exists another ShortcutsHistory.xml file, which only contains the Project's UUID XmlAtrribute string value. stored to both <RoamableRootPrefix>\\Project Management\\ShortcutFolders.xml, and CivilDocument.Settings in kind... Would it not then be simpler, to store the Data References in ..\_shortcuts\ShortcutsHistory.xml file respectively with an AECC* Object XmlNode separating them, rather than an entirely dependent sub-folder structure only to store each XML file individually?

The whole things is just overly complicated, to my simple mind.