And what is being fed into that node? What do its inputs look like? We need to see everything that’s happening in order to have any idea of what might be causing the problem. If none of the inputs are null or invalid (deleted) then we’ll also need to see the python code.
all inputs are strings from an excel sheet. except for the global parameters those are numbers.
Python code where the warning apears with IN0,1,2:
import clr
clr.AddReference(‘RevitAPI’)
from Autodesk.Revit.DB import *
def find_matching_element(elements, element_type_name):
matching_element = None
for element in elements:
# Controleer of de naam van het elementtype overeenkomt met de vierde letter van de elementnaam
if element.Name and len(element.Name) >= 4 and element_type_name and len(element_type_name) >= 4:
element_name_fourth_letter = element.Name[3]
element_type_name_fourth_letter = element_type_name[3]
if element_name_fourth_letter == element_type_name_fourth_letter:
matching_element = element
break
return matching_element
if len(IN) == 3 and IN[2]:
if isinstance(IN[0], list) and isinstance(IN[1], str):
# Haal de elementen op uit IN[0]
elements = IN[0]
# Haal de naam van het elementtype op uit IN[1]
element_type_name = IN[1]
# Zoek naar het overeenkomende element
matching_element = find_matching_element(elements, element_type_name)
if matching_element:
OUT = matching_element
else:
OUT = "Geen overeenkomend element gevonden."
else:
OUT = "Ongeldige invoer. IN[0] moet een lijst van elementen zijn en IN[1] moet een string zijn."
else:
OUT = “Geen of ongeldige invoer ontvangen in IN[2]. Wacht tot er een invoer is ontvangen voordat de elementen worden teruggegeven.”
Your screenshot titles are not visible.
Use this as a guide to get an image of the graph we can read.
1 Like
im sorry for not giving you the right information to help me.
This is hopefully good.
The Python code (where the warning apears) you can find in the post above
Yup, that helps. The issue is that you’re retrieve elements in multiple places, before and after they’re being modified.
The areas circled in red are everywhere that you get all Group elements from the model. There’s no need to get them multiple times when they’re the same set of elements. The problem though, is that the first thing you do is get those groups, filter one out, and ungroup it. So at that point the group no longer exists. But you still have those other locations where you’ve pulled the group and attempt to use it in your Right Wall, Back Wall, LZG, and VZG sections.
The transaction node is only partially helping here because you don’t have it connected to anything. Remember a transaction node needs to be used like a Wait node. It’s used to define the order of operations within your graph. If it’s not connected to anything then it’s not dictating what runs after the transaction has been committed. You’re just running your graph and also throwing a random transaction in there.
What you should be doing instead, is to separate the list of Group elements into the one to be ungrouped and the rest to remain grouped. Then you can pass the remaining groups directly into the other sections instead of collecting the original list of Groups again.
I think i did what you told but it still gives the same warning at my LZG and VZG. only there so i find it strange.
good thing to know is that only RZG and AZG are in a overlapping group.
https://r2.easyimg.io/nz0l43cd3/dynamo_code_intopia_5_2024-03-29_10-15-48.png
If the group you’re ungrouping is the only instance of its type then the list of GroupTypes is also out of date. This is where you’d need a Transaction and a Wait node to ungroup the filtered group first, wait for that transaction to commit, and then pass on the GroupType class to get the remaining group types.
You might be able to just bypass those missing GroupTypes with a try/except loop instead, but I’m not sure if that would work in this case. Better to just deal with the order of operations.