I cant grab this sheet with a bool mask or item at index?

Trying to prevent duplicate sheet creation from excel sheet list so we can run the same excel file over and over, updating our sheets but not duplicating ones we already have.

Every other sheet number is filtered out by a get all indices node. A800 is being missed. Tried running a bool mask on it after the fact. Still wont get filtered out. Am I missing something obvious here?

Hi @J_Sanford - You have different List Levels on your input lists. Easiest suggestion here is to simply use List.Flatten on your singular A800 string before it goes into the searchFor port of the String.Contains node, as it doesn’t appear you need this list structure downstream :slight_smile:

1 Like

Im trying to learn how to use levels better so I dont have flatten list all over the place lol. Also sometimes I have to keep the list structure.

In this case what is so odd is I was already using list.setdifference to compare a list of sheet numbers to be created to a list of sheets that already exist, and its filtering out all sheets except for this one which was really odd. There are a dozen other duplicates from the excel file I am testing with.

Given that I am working with Data shapes I tried testing out of Orkestra instead of running native from Dynamo bc sometimes I get weird bugs when re-running a data shapes graph. Same thing. All other duplicates are filtered out except A800.

so I tried grabbing it with a mask. Shouldnt level 1 compare that item with every item in the other list with longest lacing? that is my understanding of levels but like I said, I am struggling to fully grasp them. I usually just tinker with level combinations until I get expected results.

This is a somewhat complicated graph, I am wondering if this is a data flow issue now. I am just showing a snippet here, but perhaps when its comparing these, although they seem to both be entering the nodes, they are not entering at the right timing?

It looks like there might be an empty space on the end of your string that you are searching for. Use the string length node to check as below:
image

2 Likes

Hi @J_Sanford ,

It seems your “searchFor” string possible has a whitespace at the end.

From your selections it seems that your “searchFor” string has an unwanted whitespace (or 2) at the end. Please try String.TrimWhitespace :smiley:

1 Like

@Daan snap :wink:

2 Likes

Haha didn’t see you typing the same solution :handshake:

2 Likes

Hi @J_Sanford - Looks like both @haganjake2 and @Daan found the problem :smiley:

Your original solution requiring the keeping of List Levels will work when that space is removed. Note you can use the String.TrimWhitespace node to help here.

Also, feel free to use the Object.Type node lavishly as it will tell you the type of data flowing through - in your second example your data in the top List.Flatten node looks already to be strings, so you can remove the String from Object node entirely.

As far as List@Level goes, I suggest you watch @jacob.small 's presentation on Processing data effectively using List Levels as it goes in depth into how List Levels work.

3 Likes

facepalm. oof not getting enough sleep. Someone put a space at the end of an excel entry. I was super embarrassed until I realized this was coming from excel and not my fat fingers! Thanks lol. Now I go back and trim the whitespaces from all of my excel graphs, yay Tuesday.

1 Like

Thanks for this video! So now we have an addition to working with excel in Dynamo best practices. On all my filters and grab indexes, convert to strings and remove white spaces so my search doesnt break. :smiley: Also, loving your black dynamo interface, thats in the new release? when does that come to Revit?

Ah, the part of your Dynamo (And all software really) journey when you need to start building around user error, edge conditions and dirty data :smiley: While it might be a tad annoying, it’s also extremely satisfying to get right and will educate you a lot in the process! :books:

Typically, in any given graph, you’ll want to go through a process of:

  1. Collect data
  2. Clean data <— This is a biggie!
  3. Filter data
  4. Do stuff to data
  5. Push data out somewhere

The good thing is, nodes like String.TrimWhiteSpaces enable you to do a lot of this kind of thing :slight_smile: There is also RemoveIfNot and a bucn of other query nodes to help out.

Knowing how the data comes in is useful too, so using Object.Type nodes lavishly will help educate you on that. Side note, on the Data.ImportExcel node you’ll be able to simply feed in a true boolean into readAsStrings to get the data returned to you as a string.

image

As far as the new UI goes, yes this is Dynamo Core 2.13, which is going to be released in all our hosts, Revit included, in the not-to-distant future! We can’t give an official date, but it’s usually around the same time each year, so if you look at when Revit 2022 was released that is it’s ballpark :slight_smile:

1 Like

Me spending hours testing every single way a user could break my graph. Users breaking it in the first 5 minutes. Thats the life! :stuck_out_tongue:

2 Likes

Best thing to do is give it to your best user who breaks stuff straight away :stuck_out_tongue: So you can iterate faster. Internally at Autodesk we use QA Engineers whose job it is to break stuff.

3 Likes

Not much different than design of a building, but you get to implement fixes fast as opposed to waiting for the next project to get it right… I’m still waiting to implement that perfect stepped plinth block detail at the corner baseboard to door trim and flooring transition strip 15 years later, but the edge case for that Dynamo graph has been improved six times this week alone based on user feedback. :slight_smile:

The ability to break stuff quickly and with an eye on ‘why’ is a very important and under rated skill. Don’t forget the lessons you learn today years down the line.

2 Likes

Wow, I need to download the latest Dynamo version just to stare at.

It looks shit hot!!!

Wow

4 Likes