Modeless Door Lister and Deleter

I arrived safely back home after taking a tranquil and uneventful train ride from Milano through Switzerland.
No more airplanes or airports for me this year!
There was actually not all that much snow in sight, and no disturbances whatsoever.
Now I have a couple of days to try to pick up the threads of my normal life again, both work and private, after a full month of nonstop conferences and travelling.

Here is a pretty little sample application by Agnius Vasiliauskas, who also runs a very interesting blog named

Coding experiments
covering
a number of programming problems in various languages, with a lot of solutions especially around mathematical Euler problems, image manipulation and analysis.

Agnius made his first excursion into the Revit API, with the following goals:

  • Create a Revit add-in with the following features:
  • Display a modeless form populated with all door instances in the project.
  • Show a preview image of each door in the form.
  • Add an option to delete each door in the DataGrid context menu.

Agnius adds:
I want my work to be useful for everybody else who develops for Revit.
Because of this, I send you my work, with the hope that maybe you will find it useful too.

I created this add-in entirely from scratch based completely on the following publicly available information:

Here is a

screen snapshot of the add-in form
to provide a quick preview:

List project doors

Here is the complete
Visual Studio 2010 C# project
this Revit add-in as well.

Some of the solutions incorporated into the project are the

modeless dialogue handling
using the

Idling event
to
communicate with Revit and the

ElementType preview image
.
I totally agree that it can prove useful for others as well.

Agnius’ project door lister is a really impressive example of what somebody with good programming knowledge can achieve using the Revit API in very little time, starting from absolutely zero.
Very many thanks to Agnius for sharing this!


Comments

7 responses to “Modeless Door Lister and Deleter”

  1. This sample is so cool! thanks for sharing this!
    Per my experience, just once concern: I noticed the
    modeless Form was initialized and exists within Command class, it’ll be better & safer if the Form exists within Application class? because the Command and its resources may be GC-ed after exectuing the Command? I ever played with the SDK EventsMoniter, all forms resources belong to Application… Btw, your shared sample works well currently, my comment is just FYR.

  2. Dear Jim,
    Thank you very much for your appreciation, completely due to Agnius, of course!
    And even more thanks for the hint about the modeless form resource ownership.
    I never thought about that before.
    How exactly would you suggest fixing this?
    Simply moving the variable declarations from the Commands class to the Application class, or what?
    Yes, I can see that the modeless forms in the Revit SDK EventsMonitor sample all live in the ExternalApplication class.
    Good point and great catch!
    Cheers, Jeremy.

  3. Dear Jeremy
    this question is not really related to this specific post above. but i have no other way to contact you ;)
    i was wondering about 2 things for cording and maybe you know if it would be possible (and if, how)
    1) Coordinates. for a pileplan i really want to get the X and Y (and if possible Z too) to be used in the Schedules.
    Now i found some stuff like “RBS_PROJECT_LOCATION_PARAM” and i think this is what should be used ?
    maybe you can make some info on this subject too ?
    2) Schedules have no option within the revit 2011 program to sort/filter on the Type name of elements. so currently we have added a text parameter and make it the same as type name by hand. and than it is possible so sort/filter on that. but as you can see it is a real de-tour. now i wonder, how you look at this problem? again i found this “ALL_MODEL_TYPE_NAME” and maybe it would be possible to link some param to this one ? so there cant be made typing errors ?
    maybe this can be a nice subject too for this blog ?
    Dante

  4. Dear Dante,
    Thank you for the suggestions!
    Yes, these would definitely be wonderful subjects for the blog.
    Right now I have no time at all for research, unfortunately, we have masses of ADN questions, a backlog from the Developer Days conference tour, and end-of-year administrative tasks.
    I wish I had more time…
    Still, I can definitely say that the second issue seems very easy to address in one way or another. You could for example create a shared parameter and simply programmatically populate it with the type name of each element. That is really easy to do.
    Cheers, Jeremy.

  5. im still not very into the coding myself. but some of the colleagues are.
    I will aks them too to take some look at it later on, although i guess they are also pretty busy at the moment ;-)
    looking forward to the blogs.

  6. hi Jeremy,
    IMO, moving the variable and its accordingly codes to application is one good enhancement, it can avoid potential resource problem mentioned above, though this sample has no such problem currently.
    As a matter of fact, the idling handler(app_Idling) is yet another potential ehance: because it belongs to Command class, it has same defect with Form resource, it’ll be better if this handler belongs to Application class too.
    In other words, if events will be triggered by UI operations(or outside Command domain), it’s safer if the handlers/resources live within Application class.
    Comments above are just personal best practicses, FYI.

  7. Hi Jim,
    Thank you for the suggestions, they make good sense to me!
    Cheers, Jeremy.

Leave a Reply

Discover more from Autodesk Developer Blog

Subscribe now to keep reading and get access to the full archive.

Continue reading