This is Jeremy Tammik's Typepad Profile.
Join Typepad and start following Jeremy Tammik's activity
Join Now!
Already a member? Sign In
Jeremy Tammik
Switzerland
Interests: rock climbing
Recent Activity
Dear Ammar, 1. Check in the Visual Studio debugger what type your variable 'elm' really has. That may clarify a lot. 2. No need to submit to ADN. Submitting to the Revit API discussion forum achieves exactly the same thing. Unsolved ADN member requests are automatically escalated to ADN after a little while. Cheers, Jeremy.
1 reply
Dear Dave, Thank you for your comments, which I will reinterpret as constructive questions that raise interesting issues which help illustrate some API design principles and future trends important and worthwhile understanding. I asked Arnošt Löbel for an in-depth explanation, and he replies: Boy, is that a loaded question of what? Where do I start? I am afraid I cannot give a satisfactory answer and be brief at the same time. I’ll try to answer in stages for that very reason. A) Very brief explanation We tend to use functions which take or return element Ids rather then element objects because: It’s faster It’s safer It’s consistent and ties directly to what Revit does internally B) Detailed and boring explanation When we originally exposed the API (2005?), there was no direct link between the API and internal Revit code. That had turned out to be a maintenance nightmare. As the API has developed from tiny to large and huge we have realised we simply cannot maintain two parallel hierarchies. That’s why we have developed a framework which allows us to generate the public API directly from the internal native code. Now, basically, what we Revit programmers see, the API programmer gets. Sometime we add certain public method for the API programmer’s convenience, but the majority of the API is pretty much a mirror of Revit internal classes and interfaces. This applies both to the case of methods using Ids as well as the originally used element creating factories. For the latter, it’s very straightforward: We simply do not have such factories internally and we would not like having them. We believe that element creation is easier when it lives with the element class itself. It is also discoverable better that way. As for the element Ids - it has been part of Revit coding standard pretty much since ever. I mentioned that the main reasons are safety and speed. We often can do with just element Ids because that allows us to use elements without loading them to memory. For example, if I am looking for certain kind of a view, I can quickly get a list of their Ids, test what they are without expanding them (this is a fast test), and then only get the view I need. That mean I would be expanding one potential element only instead of, say, some hundred of view elements. The safety aspect has to do with the fact that element objects can become inaccessible when deleted (naturally) or undone or redone. Such operations are not always obvious or visible to the internal programmer who holds a pointer to an element, which leads to very undesirable problem of dangling, invalid pointers. If the programmer uses the element's Id instead, however, then operations on the element are safe. All the programmer needs to do is to test if the element obtained for the given Id is NULL or not. Yes, it is somehow less convenient, but it is incomparably safer with almost no performance penalty. We have made internal element lookup so fast, that it is practically instant. C) The case of Pipe creation On top of the above explanation, there is more about this API that perhaps deserves further explanation. I would need to talk to the MEP team to be certain, but I have seen the pattern in other APIs, thus I assume my guess will be very close to what the MEP folks would tell me. The changes the user see in 2015 are due to our continuing effort to separate Revit UI layer from the underlying model, to which we typically refer to as Revit DB. Without going into great details, the separation between those two should be such that the DB does not know about the UI, while the UI can know about the DB. Makes sense? So, even though it is not apparent when looking at the original pre-2015 pipe creation, the method (which is obviously a DB method) used to reach out to the UI layer to fetch the current type a pipe would be created with if the creation started via the UI. That, for us, is no longer acceptable and it is not how Revit works internally. The original pipe-creation method did what it did because it was written manually and did nor reflect Revit internals. With our effort of tying the API tightly with Revit internals, such approach is no longer possible. The API programmer now needs to do what Revit programmers do too, which is: If there is UI, find out via the UI interface what the current type is and use that. If UI is not accessible (for whatever reason), the programmer simply must know what type is to be used. I hope my answers are satisfactory. I realise they are not the briefest, but I tried my best. Many thanks to Arnošt for his detailed explanation! I hope this helps. Cheers, Jeremy.
1 reply
The first Autodesk Cloud Accelerator completed last week with great success. As a result, the Autodesk Cloud Accelerator v2 has already been announced, in quick succession, on June 1-12, 2015. What is this cloud accelerator thing? Simply put, a two-week... Continue reading
Posted 3 days ago at The Building Coder
Image
Developers have been requesting a Revit API class diagram for years. There used to be one back in the dawn of time, up until the Revit 2010 API. Now the question came up again with a happy resolution in the... Continue reading
Posted 5 days ago at The Building Coder
Dear Peter, Thank you for your appreciation. Glad you like it! Have you had a look at the possibilities to generate IronPython code from Reflector or JustDecompile? http://stackoverflow.com/questions/19632265/emitting-ironpython-code-in-c-sharp Cheers, Jeremy.
Toggle Commented 7 days ago on Rotating a Plan View at The Building Coder
1 reply
Dear Vilo, Thank you again for initiating all this, and for your important observations regarding the multiple selection issue. Actually, I think the status bar is very well accessible using UI Automation, and, unless I misunderstood, Revitalizer alias Rudolf Honke just demonstrated how to do so to list and switch design options: http://thebuildingcoder.typepad.com/blog/2015/03/list-and-switch-design-options-using-ui-automation.html Cheers, Jeremy.
1 reply
Dear Harry, I guess with a family instance, you cannot use CombineElements. That really just leaves InstanceVoidCutUtils, I think. Here is an overview of a couple of 3D Boolean possibilities: http://thebuildingcoder.typepad.com/blog/about-the-author.html#5.30 Cheers, Jeremy.
Toggle Commented 7 days ago on Sustainably Chugging Along at The Building Coder
1 reply
Dear Harry, Thank you very much for helping and pointing it out! Cheers, Jeremy.
1 reply
Dear Luigi, Hey to you too! Thank you very much for your appreciation, very glad you like it! Cheers, Jeremy.
1 reply
Dear Peter, Thank you very much for your appreciation, very glad to hear it! You provided a great help for the entire community. Have fun and good luck with the Revit API. Cheers, Jeremy.
1 reply
Image
Last week we discussed the SpatialElementGeometryCalculator sample for calculating gross and net wall areas that in turn led to the discovery of the FindInserts method to retrieve all openings in a wall. Both of these were prompted by the Revit... Continue reading
Posted 7 days ago at The Building Coder
Dear Vilo, Thank you again for this important suggestion. I passed it on to Phillip as well, and he confirms that it is even more useful in other way as well, e.g. for compound walls. I published the new findings and updated C# solution as a new post: http://thebuildingcoder.typepad.com/blog/2015/03/findinserts-retrieves-all-openings-in-all-wall-types.html Thank you! Cheers, Jeremy.
1 reply
On Tuesday, I presented the new SpatialElementGeometryCalculator sample for calculating gross and net wall areas. It discusses a whole bunch of interesting aspects, e.g.: Use of the SpatialElementGeometryCalculator class. Porting a VB.NET Revit add-in to C#. Use of the temporary... Continue reading
Posted Mar 19, 2015 at The Building Coder
Dear Vilo, I see what you mean now, of course. In the code above, the 'wall' variable is of type Element. I added the following debug code to verify that at least the number of openings retrieved is equal: // This approach is much more efficient and // entirely avoids the use of all filtered // element collectors. IList inserts = ( wall as HostObject ) .FindInserts( true, true, true, true ); Debug.Assert( lstTotempDel.Count.Equals( inserts.Count ), "expected FindInserts to return the same openings" ); The GitHub repository code is updated now. Thank you! Cheers, Jeremy.
1 reply
Dear Vilo, That is a very valid question indeed. The simple answer is: I was unaware of it. In olden times, methods similar to that shown above were the only way to retrieve this information. Hence, for instance, this relationship inverter: http://thebuildingcoder.typepad.com/blog/2008/10/relationship-in.html Thank you very much for this valuable hint! By the way, there is no need to say 'wall as HostObject', because the wall is a HostObject, being derived from it. You can simply use wall. FindInserts directly. Cheers, Jeremy.
1 reply
Dear Arif, Thank you for your appreciation. I am glad you are making progress. Your code does not make much sense to me, though. Are you sure it even compiles? The setout point application basically shows you all there is to know about obtaining XYZ coordinates from Revit element geometry. You should possibly do some more reading and experimenting before asking any further questions :-) Cheers, Jeremy.
1 reply
Dear Arif, I summarised our little conversation and added a few more pointers that might be of interest to you here: http://thebuildingcoder.typepad.com/blog/2015/03/calculating-gross-and-net-wall-areas.html#2 I hope this helps. Cheers, Jeremy.
Toggle Commented Mar 17, 2015 on Room and Wall Adjacency at The Building Coder
1 reply
Dear Modar Mayya, Sorry, no idea. Cheers, Jeremy.
1 reply
Image
Determination of gross and net areas and volumes is fundamental to BIM. Here is an interesting solution to determine the gross and net area of a wall, i.e. with and without its openings, making use of the SpatialElementGeometryCalculator and the... Continue reading
Posted Mar 17, 2015 at The Building Coder
Dear Vilo, Thank you again for your wonderful idea! I published it as a stand-alone post now: http://thebuildingcoder.typepad.com/blog/2015/03/element-selection-changed-event.html Cheers, Jeremy.
Toggle Commented Mar 16, 2015 on Element Level Events at The Building Coder
1 reply
Many add-in developers are interested in being notified when the current selection changes in the Revit user interface. Among other things, it led to the implementation of the selection watcher using the Idling event and was one aspect of the... Continue reading
Posted Mar 16, 2015 at The Building Coder
Dear Vilo, Thank you for your update, permission to share and pointer to the current limitations. I implemented a new external command for The Building Coder samples exercising this: https://github.com/jeremytammik/the_building_coder_samples/blob/master/BuildingCoder/BuildingCoder/CmdSelectionChanged.cs Obviously it would normally not be used in a command, but on startup in an external application. Cheers, Jeremy.
Toggle Commented Mar 16, 2015 on Element Level Events at The Building Coder
1 reply
Dear Vilo, That is an absolutely superb idea and brilliant little workaround. I'll promote it to a main blog post asap. Thank you! Cheers, Jeremy.
Toggle Commented Mar 16, 2015 on Element Level Events at The Building Coder
1 reply
Dear Arif, Thank you for your appreciation. I am glad you like The Building Coder. There are a lot of discussions on getting the wall area, e.g. Mass quantities: Revit SDK MaterialQuantities sample http://thebuildingcoder.typepad.com/blog/2010/02/material-quantity-extraction.html 2D Polygon Areas and Outer Loop http://thebuildingcoder.typepad.com/blog/2008/12/2d-polygon-areas-and-outer-loop.html Here is a recent discussion on getting the wall net and gross surface: http://forums.autodesk.com/t5/revit-api/door-window-areas/td-p/5535565 For the orientation, here are some starting points: Azimuth http://thebuildingcoder.typepad.com/blog/2008/10/azimuth.html Facing North http://thebuildingcoder.typepad.com/blog/2010/01/project-location.html Cheers, Jeremy.
Toggle Commented Mar 16, 2015 on Room and Wall Adjacency at The Building Coder
1 reply
Hi Balaji, Thank you! I will add the final result to the main blog post above once we know. Cheer, Jeremy.