Immutable UniqueId and Revit Database Explorer

The initiatives to improve RevitLookup and move it forward to become an ever more flexible and powerful tool are multiplying; meanwhile, take care handling and trying to convert between element ids and their unique ids:

• Immutable UniqueId, mutable element id
• Revit database explorer

Immutable UniqueId, Mutable Element Id

Question: Can I safely assume the integer value of the last part of an Element UniqueId interpreted as a hexadecimal value always equals its ElementId integer value?

This was suggested by the article on UniqueId, DWF and IFC GUID.

I encountered a situation where the last portion of the unique id hex value differs from the element id:

• UniqueId: e41507ae-ace2-4c44-8d8a-072f18908bea-0004d4c5
• Integer value of 0004d4c5: 316613
• ElementId: 316614
• Expected last hex string of the UniqueId : 0004D4C6

Here is the element data displayed by RevitLookup:

Here is the hexadecimal conversion of the element id integer value:

Reproducible code snippet:

  static async Task Main(string[] args)
  {
    var a = "e41507ae-ace2-4c44-8d8a-072f18908bea-0004d4c5";
    Print("Revit UniqueId: " + a);

    Guid episodeId = new Guid(a.Substring(0, 36));

    int elementId = int.Parse(a.Substring(37),
      NumberStyles.AllowHexSpecifier);

    Print(" EpisodeId: " + episodeId.ToString());
    Print(string.Format(" ElementId: {0} = {1}",
      elementId.ToString(), elementId.ToString("x8")));

    int last_32_bits = int.Parse(a.Substring(28, 8),
      NumberStyles.AllowHexSpecifier);

    int xor = last_32_bits ^ elementId;

    a = a.Substring(0, 28) + xor.ToString("x8");

    Print(" Guid: " + a + "\n");
  }

Answer: I would not endorse any of this procedural conversion. It could change at any time. In this particular example, it is likely that this element's id changed as a result of synchronisation activities in a workshared models. Newly created elements' ids are not fixed until they have been synchronized for the first time, as elements created by others may end up with the next id in sequence.

Response: Yes, the RVT model is a workshared one. It makes sense now. I will not use this UinqueId-ElementId conversion that might change at any time.

Many thanks to Scott Conover for clarifying this behaviour.

Revit Database Explorer

NeVeSpl initiated a new RevitLookup discussion #141 presenting the Revit database explorer (RDBE) project:

Let me join the race to build the first fully working WPF version of RevitLookup. I know that Nice3point is working on one, cf. Enhancements #124, and that chuongmep is working on RevitLookupWpf. I started last, two weeks ago, and mine is almost ready 😊; there are still a few things to correct, but it is already usable:

github.com/NeVeSpl/RevitDBExplorer

This animation demonstrates the possibility to query the Revit database interactively from the UI:

Many thanks to NeVeSpl for this exciting initiative!

It will be interesting to see how things pan out in the long haul. Optimally, maybe the three separate projects can converge and exploit synchronicity... good luck and much success to all three!

The interactive command line interface to drive the creation of filtered element collectors might fit in very nicely into a more complete interactive shell, like the initiative of @chuongmep to reinvigorate RevitPythonShell and hook it up with RevitLookup

Nice3point adds: Sounds interesting; my team and I will update the interface as soon as we have time, there will also be a search, OTA update and new context menu elements. Here it is important to understand that what is needed is not WPF / WinForms, but the possibility to extend the functionality. It’s more difficult to do this on Forms, where the logic is mixed with the UI, which is bad.