HostApplicationServices.WorkingDatabase = xdb you may need to set the WorkingDatabase to Depending on the operation you're performing, Make sure the original symbols are loaded Var xf = XrefFileLock.LockFile(xdb.XrefBlockId) "\nUnable to modify the external reference. IsFileLockedOrReadOnly( new FileInfo(xdb.Filename)) If so, get its Database and call the function Check whether the associated BlockTableRecord is Tr.GetObject(id, OpenMode.ForRead) as BlockReference Loop through the contents of the modelspace drawing and change all of its circles to be dashedīt, OpenMode.ForRead Get the database associated with each xref in the The simplest way to attach the xref is via a commandĮd.Command( "_.-ATTACH", xloc, "_A", "25,12.5,0", 5, 5, 0) "It may be open in the editor or read-only." "\nUnable to erase existing reference file. after erasing the file if it already existsĮx is IOException || ex is UnauthorizedAccessException We're going to save our file in the specified location, Var c = new Circle( Point3d.Origin, Vector3d.ZAxis, 1.0) Create a Circle inside a Polyline boundary Using ( var tr = db.TransactionManager.StartTransaction())īt, OpenMode.ForWrite Using ( var db = new Database( true, true)) Create our Database with the default dictionaries and Using Ĭonst string xloc = CommandMethod( "CRX")] It can be extended with additional file access exceptions, if the two that I’ve included don’t end up covering the various scenarios. We do this using this approach to check whether the file is in use, extended to also detect whether the file is read-only on disk. So we need to preempt the exception, avoiding the conditions under which it would be thrown. The other important step was to check whether the xref’s underlying file is accessible for write: if the drawing is open in the editor or is read-only on disk (unlikely in our scenario, as we’re creating it) then the XrefFileLock.LockFile() operation will throw an exception (but also keep a file lock in memory which will throw another exception when eventually finalized… not good).
This step wasn’t needed for loading linetypes, but I’ve left the code commented out for setting the WorkingDatabase appropriately: you may well need to uncomment it for your own more complex operations. The main “trick” we had to resolve when using WblockCloneObjects() was to set the WorkingDatabase to be that of the xref. If that linetype isn’t loaded it’ll go ahead and load it. The second command is called CHX (for CHange Xref) and this is the more interesting one: it attempts to edit any external reference found in modelspace, manipulating each one to have all its circles given the “dashed” linetype. There’s nothing very special about this command: we just create an external Database, save it to disk, and then run the standard ATTACH command via ed.Command(). The application is split into two separate commands: our CRX command (for CReate Xref… yes, I know this name’s a bit confusing) will create an external drawing file – consisting of a circle with a polyline boundary around it – and reference it in the current drawing. We’re going to implement a slightly different scenario, where we modify an external reference to load a linetype and apply that to all the circles in its modelspace. In this post I’m going to show the steps we ended up following to make this work. She was using WblockCloneObjects() to copy a block definition across from a separate drawing into a particular xref, but found some strange behaviour. She was using the code in this helpful DevBlog post, but was running into issues. A member of one of our internal product teams was looking to programmatically modify the contents of an external reference file. An interesting query came into my inbox, last week.