Order of execution problem: changing same parameter twice

Hi there!

I’m building a Dynamo script to number doors based on the room they’re in. I’m able to read the FromRoom and ToRoom parameters through a Python snippet I found somewhere, and I’m passing the number and name of the rooms to custom shared parameters on the door (OPA_RoomA_Number and OPA_RoomA_Name, same for RoomB) which can then be displayed on a tag as desired.

A problem arises when I’m trying to “reset” the room name and number before setting the actual room numbers back into the doors. I need to do this because when a room is deleted or a door is copied to a spot that has no room on the other side, the door maintains the previous room name and number in its custom parameters even after the Dynamo script has been run. This is dangerous since it’s then possible to have wrong room numbers on door tags. So I thought I’d first replace all custom parameters with a “-” string using Element.SetParameterByName, and then run the python script and set the parameter accordingly from the FromRoom or ToRoom parameter with another SetParameterByName.

This doesn’t always work. I’m assuming it’s to do with node execution order. Since I’m manipulating the same parameter twice, sometimes some doors FIRST change the FromRoom parameter value, and THEN replace it with the blank value even though the reset operation occurs first in the node flow. Is there a way to ensure that nodes are executed in the right order? I tried Transaction.End but I’m not sure I understand how it’s supposed to work.


Attached is a screenshot of the Dynamo definition, and a door between two rooms that only reads the number and name of ONE of the rooms. As you can see the lower room is absent from the door’s parameters, even though the door on the left correctly reads the room number (111)

The yellow nodes are because some doors don’t necessarily have FromRoom or ToRoom (these are exterior doors) so the room lists end up with null references. I’ve worked around this but as a sidenote it would be nice to be able to ignore null references and pass on null values in these situations (I wouldn’t have to manually reset the “empty” FromRoom or ToRoom if that was the case). :slight_smile:

Dynamo version, Revit 2017. Thanks for any help you can offer!


After some further troubleshooting I’ve concluded that apparently the problem is not order of execution, but rather the null references in the FromRoom and ToRoom lists. As soon as one of the doors has no room on one side (such as the leftmost, exterior door in the screenshot above), it results in a null entry in the ToRoom list. For some reason BOTH the FromRoom and ToRoom of this particular door are then absent from the other doors as well, resulting in the two other doors having no Room 111 in their parameters. Weird behaviour since the exterior door itself DOES have the Room 111 in its RoomA parameters.

Everything works when I plug in the AllElementsOfCategory node directly to the FromRoom and ToRoom python nodes and the SetParameterByName nodes in the end. Which is weird because the nodes in the beginning pass on the exact same list of Doors, only after doing some parameter manipulation. In any case, as soon as I do it that way, some doors randomly stop updating either the number and name of one of the rooms, or in some cases they only display the NUMBER of one room correctly but have the NAME as the blank “-” string (or the other way around). I don’t understand how this kind of erratic behaviour is even possible… :frowning:


Looks like it might be… the order of execution of the particular Doors that lead from/to Rooms that have at least a single Door leading “nowhere”? I know, right!

Complete Doors list after RoomA and RoomB parameters have been set to “-”:

Complete Doors list directly from AllElementsOfCategory (identical to the previous list!):

Situation after RoomA and RoomB number and name are reset; some doors (in rooms that have at least one door leading outside) keep the “-” in the number, name, or both (when the script is rerun, RoomA and RoomB may flip around so that the other room is blank and the previously blank one is correct):

Situation when RoomA and RoomB parameters are set directly after getting AllElementsOfCategory: everything works, RoomA and RoomB parameters are updated reliably (but if some door no longer has either FromRoom or ToRoom, the old data is not wiped). This Door list is identical to the situation above, which somehow led to erratic behaviour.

I’m running out of ideas… for now I’m going to have to live with not wiping old data before reading the FromRoom and ToRoom info. Can this be filed as a bug?

Don’t you simply want to set the parameters to “-” if there are no data, and to the room info if there are data? Then there is no ‘reset’ needed.

If you want a reset, perhaps just make that a separate graph.

If you post your RVT and DYN, you may be more likely to get help.

@truevis: That’s exactly what I want. Ideally I’d need to check if a list has null entries (such as the FromRoom and ToRoom lists), and the graph would then feed an empty string to the corresponding door’s parameter. I haven’t found a way to do that.

Instead of inserting empty data to the parameter value, the SetParameter node doesn’t execute at all if the input is null. This results in that door to maintain its old (outdated) parameter value. Maybe I’ll try to modify the Room lists and somehow get rid of the null references while maintaining the list length (because it needs to match the correct door). Essentially the null room names and numbers need to be replaced with blank strings instead of Null values… If you’ve got some ideas, let me know! :slight_smile:

I think I’ve got it! :slight_smile: The out of the box List.Clean is of no use, since when I preserve indices the Null values are replaced with some more Nulls. But the Clockwork node package has a List.ReplaceNull node, which allows to replace null references with a desired value (in this case a String since my list is a list of Strings). Attached two screenshots.

This is my original problem: There are three doors with no Room on the other side, so these values are null in the Room name list (a list of Strings). SetParameterByName DOESN’T EXECUTE on these indices of the list, so there are three null Doors in my final door list (even though the input Element list is complete with no nulls). The parameter values of these doors are not changed.

The ReplaceNull custom node allows for replacing the null references with a string. The SetParameterByName node executes correctly for all doors since there are no null values in the input list.

Hopefully this is useful info for anyone wrestling with a similar issue. It still doesn’t explain the erratic behaviour with some doors not updating their values every time (in the case when I try to reset the values beforehand).

[quote=“miika.liukka, post:6, topic:6553”]
It still doesn’t explain the erratic behavior with some doors not updating their values every time
[/quote]Try closing and re-opening your DYN

Hi Miika,

I’ve found the same strange behaviour, have you found a reason at all? Otherwise is there a central place to report this as a bug?



can you try to replicate the same odd behavior of the execution not appearing to happen in order if you use a parameter named something that is very unique… like “myveryuniquename” : “some name”

1 Like