How to tell (thru API) if an object is messed up.

[0001des]

I recently posted a question about an object that wouldn't allow for a shared parameter.  

To follow up that question, I have a bigger question:  How can I tell (with the API) if an object in Revit is messed up.  I have this wall, that a client made, and it has everything greyed out.  See the image:

I should add, not all the parameters are read-only.  Two survive (Structural and Room Bounding) and are writable.  This is confounding, because I was trying to make a simple subroutine that checks if the parameters are all read-only, which would assume that no new parameters could be added.  Since these 2 parameters are not read only, then there must be some writable functionality to this wall.  In 3D, the wall is invisible.  The only way I can find it, is by using the Select by ID functionality in the UI, and when I select it, there isn't any object there (or at least is visible, maybe it's there, but in a different modality).  

But while trying to do all this, I looked to see that even the "Basic Wall" Property was greyed out, which is really odd.  I would assume that ANY wall constructed in Revit would be writable/changeable.  Maybe I'm wrong.  I'm more an API person than a UI person, so I don't know the nuances of these exceptions in Revit.  Regardless, here is the major question:  Is there an API way to check if an object is corrupted like this, or is there a way to tell if the default property (like Basic Wall) is locked to read-only?

I can't use try-catch.  Too slow.  Any ideas?

[jeremytammik]

I am am not aware of any such check.

Maybe your customers should take some basic Revit product usage training before you let them loose on a real projects.

Cheers,

Jeremy

[FAIR59]

by which method do you add parameters ?

can you share the offending family ?

[0001des]

I think there is some confusion here.  I'm not guiding/training/supervising my clients.  They model stuff, then use my addin.  I really only engage with my clients if they want some enhancement, or if they find a bug.

The fact that they had a corrupted wall in their model probably had nothing to do with their skill level in Revit.  In fact, due to confidentiality, I can't reveal the owners of this model, but I assure you they are a large architectural company with lots of experience with Revit.  If it hadn't been for my utility, I doubt they would have even known that this invisible, non-user-modifiable, grey-out wall existed in their model.  

As for checking the validity of an object, I couldn't find any boolean or property or method that would allow me to check if it was a good object in Revit.  I scoured all the sub-categories and properties of the object to find anything that would be a red flag when compared to a "good" wall, but everything was the same (in the API's).    In the end, I had to use try-catch, because there was nothing else that would inform me if an object was corrupt.  It increased my processing time by over 25%, which the client will just have to eat.  

If Autodesk could provide an api for checking the fortitude of an object, that would be really nice.  If it showed a problem with an object, I could just exclude it from the loop from the beginning, and it would save a lot of time.

[0001des]

I'm using shared parameters and adding them to the object.  

I can't share the object.  I don't own this model, and the client wants it confidential.  While trying to finish this bug, I found a handful of other invisible, non-user-modifiable, greyed-out walls/objects too.  There doesn't seem to be any rhyme or reason.  

By implementing my try-catch workaround, it did increase my processing time, but at least now, I can send a list of the offending objects to the client so they can verify their geometry and parameters manually.  It wasn't my intention to make a utility that checks object validity, but I guess this is a byproduct of my subroutine.  

[stever66]

Are you sure the wall isn't in a linked project? 

That would explain the greyed out properties.

[0001des]

It's not linked.  I thought that too.  

This is a single file with the links separated.

[FAIR59]

As you can't share anything, we are flying blind here.

• I presume you use a project parameter to add the (shared) parameter to a wall instance. Simply use element.LookupParameter, check for null, and IsReadOnly.
• wall is part of a Group, check element.GroupId
• wall is a nested shared Family, check (wall as FamilyInstance).SuperComponent.
• wall is a DirectShape, check element.GetType() == typeof(DirectShape).

[0001des]

Thanks for your suggestions.  

I've checked the group ID... not part of a group.

Not a linked doc.

We are using Shared Parameters, not Project Parameters.

I'll use your suggestion and check SuperComponent and DirectShape.  This could be the smoking gun that could save me a bunch of processing time.  Thanks!