Another Grasshopper Rhino component recompute issue

Grasshopper
1

My current Grasshopper definition imports hardware like bolts and nuts from a directory using the Query Directory component.

The directory contains over 50 different files, mostly *.3dm and some *.3dmbak

I’m using the name filter to retrieve just the *.3dm files.

I just added another part to my hardware collection and the only way to get this filename into Rhino using the same Query Model component seems to be by pressing the ‘Query’ button on the component. The issue I’m facing is that this recomputes the file output which means everything downstream is recomputed.

Using the native Grasshopper Rhino components, is there a way to avoid this full recompute?

Is there maybe a way to create a smart list which only recomputes what has changed?

@kike @Japhy ?

2

Did you try connecting the output to the Event Gate of Heteroptera plugin? That might help, however then I experienced some unexpected behaviour related to usage of that component together with Content Cache…

3

Thanks for the idea, it sounds like it should solve the problem. However I’m not using heteroptera.

I’ve played around with event listeners but not yet for this problem…

4

You can observe if files have change by using the FileSystemWatcher Class (System.IO) | Microsoft Learn

5

I don’t understand how that would work.

I think the Query Directory component should work in a similar way like the Block manager in Rhino which highlights a block if it has changed.

7

Sorry, I might misunderstood the question… Usually if you want to do some action based on a change in a given folder, you can observe and react to the file-system change using this library function. With the information about what has changed, you can trigger an conditional answer. This of course involves scripting, and some understanding of event handling in Grasshopper (which requires a bit care).