UI Simple Grid confusion

Grasshopper Human UI
1

I have two Pull down Menus I want to place side by side in the main window. I load them into a simple grid but they are now stacked on top of each other. Feeling stupid, but I can’t seem to understand all the options in the Simple Grid.

How can I accomplish this?

2

I figured out the side by side placement - I needed to set the element property to graft. Now the grid is getting pushed down the window by any new element added to the Add Elements component. How can I make the grid hold order in the window?

1 Like
3

Hello there – Simple Grid tends to create a HUI object with a different tree branch level than your average HUI component. Simple way to ensure that the order of your elements stays stable is to run all of your elements into a Merge component and flatten all the merge component inputs. This will ensure there aren’t any tree order hijinx happening to ruin your UI layout.

Let me know if you need a sample, I don’t have access to Rhino at the moment.

Happy Labor Day!

Marc

4

Thanks Marc, that worked perfectly. A new issue in that layout is that I have a button (Bake All) that doesn’t revert after being pressed. If I press and hold for a moment the button does revert back to False. This is an irregular behavior that I can’t figure out. See attached image.

ButtonsFail
ButtonsFail1159×862 142 KB

5

Hello there –

Yes, unfortunately that is a known issue when using HUI buttons with functions that interact with Rhino (such as Bake, layer creation, etc) or System events (like OpenFile, etc). My solution has been to use the True-Only Button with a “Simulate Button” component that I wrote to handle the mouseup event in a callback that is outside of SolveInstance so that the button never gets “stuck”.

Here is the important code for that component:

// on first load, set output to false to avoid scheduling a solution
    bool output = false; 

    /// <summary>
    /// This is the method that actually does the work.
    /// </summary>
    /// <param name="DA">The DA object is used to retrieve from inputs and store in outputs.</param>
    protected override void SolveInstance(IGH_DataAccess DA)
    {
        
        bool value = false;
        int del = 0;

        if (!DA.GetData(0, ref value)) return;
        DA.GetData(1, ref del);


        // do not scheduleSolution when input is false
        if (!value) output = false; 

        if (output)
        {
            GH_Document gh_doc = OnPingDocument();
            gh_doc.ScheduleSolution(del, TriggerCallback);
        }
        else
        { 
            // input is false OR scheduleSolution has modified the global variable to prevent looping
            DA.SetData(0, false);
        }

        // Input false: output is false and then does not execute again
        // Input true: output is true, then scheduleSolution happens and changes to false
        DA.SetData(0, output);

        // set up for next value
        output = true; 
    }

    

    // callback to schedule a fake event, turning the output to false
    void TriggerCallback(GH_Document doc)
    {
        // set to output false on callback
        output = false;
        ExpireSolution(false);
    }

I can’t remember if you are a coder, if you need me to put this in a C# component for you let me know.

Marc

6

Not really a coder. I’ve done a bit with WinForms and Python a couple of years ago and was considering that path for these apps. The apps were fully built out in Grasshopper and used for a few years by others in the enterprise but they required a high level of maintenance as people accidentally fiddled with the Grasshopper components. HUI looked like a great alternative to totally rebuilding the .GH into Python.

No experience with C# so It would be great if you could put that into a component. I am also interested in expanding the C# code that closes the HUI and Grasshopper document. It would be great if that code could be extended to close Grasshopper as well - with Save = No.

Many thanks for your help.
Robb

7

Here’s a C# script version of the SimulateButton component.

SimulateButton-CSharp.gh (3.5 KB)

Closing the GH document a completely different component that requires a some event listener handling and special handling of the Document modified flag. That’s a project for another day!

You’re getting pretty deep into custom functionality – you should take up C#! :slight_smile:

Marc

8

Thanks a bunch Marc! That works perfectly.

My hike up the Python mountain has convinced me that competency in programming is time consuming and fragile. I haven’t touch Python in 2.5 years and when I go back into my previous work I can barely understand what I did. My only arena for programming is Rhino apps. If you were starting from 0 and wanted a windows style interface it would seem that Winforms + Python is more robust as there is no Grasshopper involved.

If I were in my twenties I would definitely take up C# as I do love learning stuff and the power of such skills. As I am long out of that phase, there are many other things calling for my time. I very much enjoy programming in Grasshopper and look forward to the moment HUI can be all that is visible when launching the app.

1 Like