Hi all,
as usual my brain refuses to grasp the simplest things… 
See below:
It shouldn’t be dealing with the nulls, so let’s just start with a simple version. What happens if you try something like:
a != null;
That should return the same boolean list that you have already.
Then you can step up to something like:
a != null ? "group" : "no group";
That should still work and reaffirm which items are valid groups and which are not.
If either of those attempts gives you a warning it may shed some additional light on what the issue is.
Another thing you should probably try is to filter the groups and make sure each one of them successfully returns a Name and an Id to confirm that it’s not a Group that’s failing.
Thank you Nick,
However, Mike’s test works as expected, so I am afraid this is an issue with my install of Dynamo and /or some package / plug in…?
In any case, by pre-screnening the valid value and avoiding feeding a null to the .Name or .Id code, I was able to get what I need…
(Also, notice I had to use @L2 and @L1 in the IF node to get the final list)
Nick, your code works, not a problem, because it does not use the “.” notation, like g.Name.
The issue is the Null values.
If I use a list of data with no nulls values, it works:
Yes, we all understand that it should work, but we have to confirm all the individual steps to identify why it’s not. If you can confirm that everything works as expected individually but just not when wrapped up into one conditional, then you’re right, it could be a conflict with another install, but I’ve never seen that without a warning pointing in that direction. If you just want a working fix, then the easiest thing would be to write a conditional in python and completely skip over the nulls. Also, the example from @Mike.Buttery should actually have the same/similar issue since the nulls wouldn’t have a Name or Id - so that seems a little weird.
I guess all I am saying is that I cannot reproduce Mike’s example which does not work for me, and I get nulls instead of those [group].Name and [group].Id
If there are no Nulls in the list of data, it works as expected.
It shouldn’t be dealing with the nulls, so let’s just start with a simple version. What happens if you try something like:
a != null;
That should return the same boolean list that you have already.Then you can step up to something like:
a != null ? "group" : "no group";
That should still work and reaffirm which items are valid groups and which are not.
These tests that you are suggesting work fine on my end.
Thank you
If you want to share an example model and script where this is reproducible then we can see if it’s something in your model or something on your machine. But if you have something working then it may not be worth tracking down at this point.
It follows another example.
Is this the normal behavior?
I am going to need to replace the Empty lists beforehand, but I am wondering if this is simply the way Dynamo works..
It might be easier to understand what’s happening if you use nodes to see how each step is interacting with the different list levels.
Firstly, the notation you’re using for ele<1> is using replication guides rather than list levels. They are related and very similar but not interchangeable. Make sure you’re using the right one for the right occasion. In this case, you’d want to use @L2 to target the sublist level rather than @L1 which targets the lowest item level in all lists.
Secondly, this gets a little weird due to the levels you’re targeting. You’re looking at a list (within a list) and returning either that same list (if it’s not empty) or a single item (if it is empty). That’s changing the dimensionality of the structure you’re targeting with list levels and that usually gets messy. The If node allows you to specify different levels for each input which makes this easier to handle.
In this case, you can get everything working with the correct list levels and the right nodes but in general I’d say it’s easier to use python if you’re going to be varying the structure of any replaced dimensions of an array.
1 Like
Nick, thank you, you are a great asset to these forums.
If I have the time, I will respond to your great explanation, which I am still digesting.
However, in the meanwhile, I wanted to post that the original question has been resolved by using Element.Element.Name(x), and with no need for @L1 in the IF node, as shown in Mike’s example.
Still, I cannot reproduce Mike’s solution, so I think we must have different Dynamo versions, or installed plugins combination.
The bottom line is, the simple formula in the code node now works, even when evaluating the direct data (nulls and groups) instead of a list of boleans.
I will test using the ID next..
Thank you all!
1 Like
Regarding the warning @Giovanni_Succi, you’re correct that the node itself is still executing the answers you are looking for and you can ignore it. The reason it is throwing that warning is due to the presence of Null in that list 
The Element.Name node is trying to access something that doesn’t actually exist or isn’t properly defined.
Think of it like this: Imagine you have a list of phone numbers, and you tell your friend, “Call the third person on my list.” But when they look, there are only two numbers. Your friend is confused because the third entry doesn’t exist—that’s similar to what’s happening in Dynamo.
In this particular case, you’re asking Dynamo to Get the name of a nothing that doesn’t exist.
Breaking it down:
- “Dereferencing” means trying to look up or use a value from a reference (like trying to open a folder that doesn’t exist).
- “Non-pointer” means that the thing being accessed isn’t actually a valid reference (like trying to grab something from an empty shelf).
- “Internal error” just means something went wrong inside Dynamo’s system, and it wasn’t expecting this situation.
1 Like