How to remove RXClasses (custom objectdbx) from DWG file

[Anonymous]

Using .Net API how can we remove RXClasses (custom objectdbx) from DWG file. I have purged all the instances of those RXClasses but if I look at at the DXFOUT of the file, I can still see those classes. Looks like in ObjectARX there is deleteAcRxClass() function to remove your custom classes from the AcRx runtime tree so essentially I want to know how to do the same thing in .NET.

[ActivistInvestor]

---

@Anonymous wrote:

Using .Net API how can we remove RXClasses (custom objectdbx) from DWG file. I have purged all the instances of those RXClasses but if I look at at the DXFOUT of the file, I can still see those classes. Looks like in ObjectARX there is deleteAcRxClass() function to remove your custom classes from the AcRx runtime tree so essentially I want to know how to do the same thing in .NET.

---

P/Invoking deleteAcRxClass() could likely become fatal if there were any instances of the runtime class encountered in any drawing that was opened in the session. Remember that your purge operation can be rolled back by a subsequent UNDO, but that doesn't also roll back your removing the runtime class(s) from the class tree.

[JamesMaeding]

typically you have to figure out how to erase the proxy objects by hand, then try with api.

I have not seen that always work though. What you do instead is wblock all to a new drawing, except the proxies/custom objects.

Even the civil batch converter uses a wblock mechanism.

We need more info though on what they are.

[dgorsman]

Indeed, as "objects" aren't necessarily "entities" living in one of the layouts.

[ActivistInvestor]

---

@Anonymous wrote:

typically you have to figure out how to erase the proxy objects by hand, then try with api.

I have not seen that always work though. What you do instead is wblock all to a new drawing, except the proxies/custom objects.

Even the civil batch converter uses a wblock mechanism.

We need more info though on what they are.

---

@Anonymous is referring to the entries in the CLASSES section of a DXF file, not instances of the custom objects or proxies themselves (which he already has purged). Purging the custom objects/proxies doesn't prevent AutoCAD from adding their runtime classes to the CLASSES section on a subsequent DXFOUT.

[JamesMaeding]

I guessed that, but thought maybe there was also some entity hanging out that was no visible, with the common one these days being a c3d parcel with 0 area.

Either way, the solution is to block all (selectable) items to new drawing and try the dxf on that.

That is very bad news for anyone trying to automate things, so its just a starting idea.

I'm not familiar with how a dwg keeps "runtime classes" somewhere. I know that object enablers or the mother arx app itself provide custom entity definitions, but would think if those are not present, and the proxies are gone, what provides those runtime classes?

Maybe the drawing remembers the classes once a custom object is added.

I am interested because I would say drawing cleaning is one of my specialties, though there is obviously (and luckily) much to learn to keep things fun.

[Anonymous]

Thanks guys for your suggestions. Finally I found a way to remove RXClasses from the ClassDictionary but still not achieved what I wanted.

(Autodesk.AutoCAD.Runtime.SystemObjects.ClassDictionary)

First off I am dealiong with AEC* non-graphic objects stored in dictionaries. The DWG has absolutely no graphic entities.

I have purged all the instances of AEC* objects.

I have removed AEC* RXClasses and verified that they are not in the ClassDictionary any more.

I have removed the associated application service from ServiceDictionary.

Still when I dxfout those AEC* RXClasses show up. If you guys have anyother ideas as to why these classes may be showing up, let me know.

Thanks

[JamesMaeding]

oh, that is easy if they are civil3d items.

Delete the "Root" node of the NOD.

like this:

public static bool PurgeDatabaseofRootNOD(Database db) {
    bool ret = false;
    using (Transaction tr = db.TransactionManager.StartTransaction()) {
        try {
            using (DBDictionary NOD = (DBDictionary)db.NamedObjectsDictionaryId.GetObject(OpenMode.ForRead)) {
                if (NOD.Contains("Root")) {
                    NOD.UpgradeOpen();
                    NOD.Remove("Root");
                    ret = true;
                }
                else
                    ret = true;
            }
        }
        catch { }
        finally {
            tr.Commit();
        }
    }
    return ret;
}

There are other reasons to do that too, especially if your intention is to not use Civil3D, and get rid of traces of it from a dwg.

See if that does it.

BTW, grab my free Purgeids program to do this to multiple drawings, email me at 123jmaeding123at123hunsaker123dotcom and I'll post it.

Remove the 123's from the email to get real one.

The Purgeids cleans other things too, like regapps, and lets you see what files are contaminated before cleaning them which most other tools do not.

I give it out for free because I want consultants to clean their own drawings before giving to us.

[Anonymous]

As mentioned before, I have already removed all the instances of AEC* objects including the ROOT item which you have mentioned in the reply.

The basic question is when we have purged all instances of custom objects, unloaded its arx/dbx which in turn removes all custom classes from runtime classes dictionary and also removes registered services from serivce dictionary, then why when we dxf out it still output those custom classes?

I have attached the same file incase you want check it. As far as I can see using API and arxdbg there is no trace of AEC* and AT_* custom classes and yet if I dxfout it write them out. 

[JamesMaeding]

I tried and see what you mean.

Its not just one aec flavor, you have from arch desktop 2007 to c3d in there, even Bentley stuff.

Running the civil3d batch converter on it did not help.

That c3d batch converter does not clean a file, it wblocks all to a new file, so I am saying the classes part went with it.

That means my wblock by hand idea is useless.

Pounding sand would be more productive than my ideas so far....

I read back and you did not mention deleting the root NOD before. Didn't mean to throw basics at you as you are on the ball here.

[Alexander.Rivilis]

@Anonymous

There is no API which can be help with deleting unused RXClass's from Database. I received this answer several years ago from ADN DevHelp.

I hope @artc2 or @Virupaksha_aithal can confirm this fact.

[artc2 · Accepted solution]

That's correct, there's no API to remove unused entries from the class dictionary.

[Alexander.Rivilis]

@artc2

Thank you for confirming this fact.

[Anonymous]

Thanks for confirming that there is no API for removing unused RXCLASSES. Then the related issue is once you cleanup all the instances of a custom class and dxfout it doesn't write code 91 (no of instances of a class) to 0 , which results in loading of arx/dbx of custom classes which have no instances. That is where my original problem started. 

[artc2 · Accepted solution]

I haven't looked at the code to be sure it is still this way, but the last time I did look, the instance count wouldn't be reset to 0 until you saved to dwg with isavepercent set to 0 so it is a full save, and then reopened.

[Anonymous]

I tried the ISAVEPERCENT var set to 0 but it doesn't seem to have any effect on the instance count of purged custom objects. Irrespective of the ISAVEPERCENT value, after I have purged custom objects, saved and closed the drawing, I have to reopen the drawing (at this point custom arx is loaded again since instance count is not 0) and SAVE it again, that is when ACAD seems to reset the instance count.

The problem is if on load the custom arx is creating some objects then its like a recursive cycle, you purge, save, close. Instance count is not reset yet so on next open custom arx is loaded again and it will recreate bunch on objects. Unless you disable demand load arx apps, I will have to see if that works in such a scenario.

[JamesMaeding]

At this point I would focus on editing the dxf file to clean things.

Not sure what problem they are causing you, but when things start getting complex, I don't trust them, and have to check the end result anyway.

Curious to hear if that would or would not work for you.

Were the unclean dxf's not importing somewhere?

[Anonymous]

I think finally I found a workflow that works for me to cleanup drawings, the following steps can be automated through a script

1. Set ISAVEPERCENT=0
2. Set DEMANDLOAD=0, prevent custom arx application from loading on demand, this will cause ACAD to convert all custom objects to proxy objects when file is opened.
3. Open the drawing.
4. Run your function to purge all proxy objects/entities from drawing, save and close.
At this stage the drawaing is clean but the instance count of purged object is still not set to zero.
5. Open the drawing again, save and close.
At this stage the drawaing is clean with instance count of purged objects set to 0.

Now even if you have DEMANDLOAD=3, no custom arxs will get loaded as there are 0 instances of custom RXClasses, tough as mentioned in one of the previous posts there is no way to actually remove the custom RXClasses.

[JamesMaeding]

Why bother with all that?

Open the dxf through a program and edit the lines of text.

I looked at the dxf made from the test file, the patterns of custom classes seemed easy to identify.

Is it that you don't want to write code to parse the dxf and clean it?

Good to know both ways, but I think my idea is far better as its many times faster than script opening drawings like twice.

Is there a flaw to doing that?

[Alexander.Rivilis]

@JamesMaeding

As far as I remember not all objects/entities (especially AEC-objects) have full dxfOut output unlike of dwgOut output. So after export dwg-file to dxf-file it  can be incomplete or damage at all.

This post can be interesting for you: http://jprdintprev.autodesk.com/adn/servlet/devnote?siteID=4814862&id=5415786&linkID=4900529