Triggering a plugin components button

Grasshopper
#1

I am desperately looking for a way to trigger a button that is coded into a component. You can see it here in Instance Manager (V1.6.2.1) in the Insert Block component.

For some reason it used to be a trigger input (on the broken old version), but now is a button on the component itself and doesn’t have a trigger input any longer.

trigger_button
trigger_button.png573×655 49.3 KB

Maybe @andheum knows a way to do this with something Metahopper-like!? The problem is that I have multiple of those components in the depth of a large definition and just need to trigger them using a button (and RCP).

I don’t know why you would create such components that for some reason include UI elements? It makes no sense at all to have a UI button included in the component and I think frankly they should not even be allowed. It saves you creating one button, but you lose so many possibilities of triggering a certain component. It’s enough that there are tons of right-click options on some components, but usually you set those once. Triggering a function however should never involve first finding the component in a large definition and having to click the button for each one separately.

@DavidRutten is it possible to have some stricter rules for GH2 please. Attributes and options should all be exposed as pins for true parametric coding. What’s your take on those buttons?

1 Like
#2

Please remember that this developer has spent a lot of time giving you something you seem to need for free. Complaining about something you don’t like is understandable, but trying to ban it seems delirious to me. There are reasons to break the automatic flow with interface actuators, one of them is simply that the developer wanted to do it that way. Another is that some operations are intended to work once and not automatically, or GH can only be used to automate? There are operations that go beyond GH logic (because they interact with other environments or because they need to solve the definition in a customized way…) and using an interface button can simplify the code. There are reasons to do so, it has advantages and disadvantages.

I understand your anger, I also faced the same problem with another plugin. But I’m tired of people trying to ban what they don’t like, that’s not right. What you can do is talk to the developer and ask for an automatable version. Or maybe he has in his library a method to automate it from code. And if not, do it yourself this component, looks like it’s just rhino functionality wrapped in GH.

4 Likes
#3

I am not trying to ban anything. And sure some plugins have special operations that don’t normally occur in native components, like with looping and so on and there are also native components that have special UI elements, like the image sampler.

The older version of the same plugin (V1.5.9.4) just had a trigger input, while the newer version (V1.6.2.1) got rid of the trigger input and replaced it with a button. Sure the developer is free to do that, but there is no reason for it that has any upside I can see other than personal preference: it breaks all definitions that used that component and updated the plugin, which shouldn’t happen for a point update. Secondly from a usability perspective I don’t see any benefit to having the button on the component. There is already a button in GH that can trigger something, why add a button to component that is now forever stuck on it and cannot trigger anything else. It breaks an otherwise automated workflow, which is kind of the point of Grasshopper.

Basically any component that has some critical functionality but doesn’t expose it as a pin will cause some issue once you start building large definitions. Like the image sampler for example. It works great, but what if I want to set the image path from something like a text file I have read - you can’t do it. It’s frustrating and just because something is free does not mean we are not allowed to give constructive criticism.

So don’t get me wrong, setting developer guidelines is never about banning anything or complaining about something I am getting for free. There are many guidelines already and I think it will benefit everyone if the amount of “unexpected” conventions from some plugins are kept at a minimum.

Once again, I am not trying to ban anything. I never say that anywhere and I don’t know how you come to the conclusion that would be the only logical step from what I was suggesting?

#4

About your original problem… what about using the old version of the plug-in or creating your own c# component to solve this?
Is that component you need for baking?

#5

Asking the developer to set rules based on biased perspectives for third party developers doesn’t seem like constructive criticism to me. But okay, I accept that you don’t want to ban anything, but you accept your bias (which we all have). You have a user approach to this, not a developer approach. Why? Bc not all users give the same use to GH as you, and many others may think that GH’s strong point is not that it is automatable, but visual. I understand perfectly your point, but the interface logic has its space, is necessary and I do not think that should be less important than other kind of logic, but depends on what for…

There are already development rules. The developer made the mistake of not updating the version properly (he should have made a separate component with other parameters, and marked as obsolete the previous version of the component). Limiting the use of graphical elements in GH seems antinatural to me, that was my idea. I’m sorry I took it the wrong way.

1 Like
#6

And by the way, a visual and a parametric version don’t have to be exclusionary. It would make sense to include both versions of those components if the component icons supported variations of the tool as in Rhino.

Another option (which is also considered a design rule when programming) is to always separate the functionality of the interface, to avoid these problems of not being able to code operations because the developer forced them into a context of user interaction. If your solution/request goes parallel to this line, then I am 100% with you, because this design pattern GH1 does not respect it.

Take a look at this, maybe you can automate it with this:
SimulateMouseClick.gh (7.3 KB)

#7

I also dislike these menu options in many cases, even the native ones like on bounding box, at some point the bool for union box became a menu option which means no more bool lists or switches to control the behavior. Although I don’t think we can ban any way a developer makes tools, understanding the limitations that sometimes flashier looking things put on the workflow is important to know for a developer. Have you reached out to them?

#8

Yeah menu options are something I’d like to avoid in the future as well. In many cases I suspect I’ll just end up making two versions of a component. But I did come up with a general way of treating inputs as items/lists/trees.

So for example the geometry input of the boundingbox component can be set to either item, twig, or tree and you’ll either get a per-shape box, per-list box or just a single box containing all shapes in the tree.

Other components such as ‘average’, will allow you to switch between twig and tree only. Etc. etc.

6 Likes
#9

Thanks for all the replies.

@maje90 The old version sadly does not support custom Attributes yet and has a bug with extracting names. The new version has the Attributes, but introduced the button instead of the trigger. I have written to Amin Bahrami, but he has not replied. Creating my own C# plugin is out of my league and the scope for what we use it. We would probably switch to Elefront, but I actually like how Instance Manager works better.

@Dani_Abalde thanks for the clarification and the possible workaround - I will check it out tomorrow

@Michael_Pryor I have reached out, but no answer yet. Amin Bahrami (dev of Heteroptera) doesn’t seem to be on here, so only place to leave bug reports is on food4rhino reviews, which is not really what it’s intended for.

#10

What are the attributes you use?
Packing up a small c# script shouldn’t be too complex.

#11

So what I need to do is:

Have a long list of block instance names (so usually a list of around 1000 taken from maybe max 10 different blocks in Rhino), position (1 plane for each block to be placed), scale and attributes (1 for each block to be placed with: new name of block, color, layer name, user attributes with severals keys and values). Then it places the instances using a trigger input.

It basically does what a scattering plugin usually does, but I want each block to be able to contain several data points using keys & values.

#12

Looking at this https://www.grasshopper3d.com/forum/topics/bake-block?id=2985220%3ATopic%3A1285316&page=1#comments
… you want to “bake” new istances of already existing blocks, right?
So you want just to specify the Nickname.

If you want to create new block from grasshopper, that’s another thing…

#13

What about decompiling and use Reflection to trigger that button? If the code is obfuscated, you can simply harvest all class members (not just those exposed to public), but seeing the original source code makes it much simpler. You can almost trigger any piece of code. If thats not working out, there are multiple different approaches. As already said, reimplementing the functionality might be the better solution then, although hacking is fun as well.
Simply find the instance in the active gh document, retreive the command, method or whatever is responsible for it and invoke that. Should be located in the custom attribute of the component instance…

#14

That’s right. But there is a few options for doing that already that work fine (like elefront) without coding. The important part is adding the custom attributes dictionary to each block. Instance Manager can do just that in it’s latest version, all it needs is a trigger input like it used to have the version before and it would do everything I need it to. So rebuilding the whole functionality just for that one minor, but critical functionality would be overkill.

@TomTom thanks for the suggestion, but it also sounds like it is out of my coding skill league unfortunately. But I’ll find a way.

Meanwhile if anybody knows how to get hold of Amin Bahrami, the developer of Heteroptera and Instance Manager, I am more than happy to pay him for adding the trigger back in (and another minor bug).

#15

Nice. It works fine, but the problem is that I have 2 of those Place Instance components that I need to trigger at the same time (or one after the other). They have the same name which can’t be changed, so there is no way to address one or the other at the moment, it just triggers the first one. It should use the GUID of the component and not just the name.
Could the function it triggers be put in a kind of for each loop and I input more than one name? But in this case it would need something other than just the name.

#16

Okay, I tried to consolidate the 2 components I need to trigger to one and it seems fine, but now I noticed that the simulate click only seems to work if the trigger and component to be triggered are both in view in GH. Once they are not the mouse cursor only jumps to the component but doesn’t press. Same goes for triggering from RCP, which only makes the cursor jump to the component, but not click.

#17

I already thought that would happen after I uploaded the file. You have to take the viewport of the canvas to the component before clicking, so it should work. When I take a break I’ll try it.

#19

Alright, so the Elefront alternative is not going to work. Its way too slow compared to Instance Manager. Well what’s really slow is the Scale component. In instance manger the scaling is done during placing, but in Elefront you have to reference the blocks and then use the normal scale components of GH and then bake them. In instance manager everything just stays as references, which is why it is so much faster I think.

Well now at least it’s only one button to press, which is already an improvement.

#20

The saga continues. I thought Human would finally solve everything, but that too is not ideal.

Instance Manager seems to be the only plugin where I can select a bunch of blocks in Rhino, set them in GH and then it does stuff only on them. Human and Elefront both rely on filtering through ALL INSTANCES of blocks in the document. Instance Manager seems to be the only one that directly works using the GUID of a black and not just the name.

There are around 130 simple blocks in the Rhino doc, but over 100.000 instances of those blocks, meaning that any component that has to filter through blocks is useless. I found a little script by Andrew Heumann here: Changing layers of blocks, hatches, etc where only the Modify Attributes node uses the GUID. Funnily enough that is exactly what I want to do - modify the attributes of a bunch of SELECTED blocks, which will then get instanced. But with Human I can’t find a way to work only on selected blocks without first having to filter. And even then the reading back of the attributes doesn’t seem to work. The name of the block as well as any user keys and values are always empty or Null!? I might post in the Human section about this specifically.

#21

I couldn’t make it work for more than one, the mouse moves but doesn’t trigger the click event. Better try to simulate that component using scripting.