Forms / Buttons / Event Handlers

Hi all,
I am trying out some forms and buttons for some potential future exploration. I see a few different ways to go about it. Some examples set up the form as a class and other just create the form as a subroutine. I see advantages to both (seems the class structure is probably the way to go?). The issue I see with the Class examples is that they always seem to use Application.Run(New Form1) Where 'Form1' is the name of the form class. When I close this form, so too closes the GH def panel and I am not able to retrieve it unless I shutdown rhino and open things up again.

If I create a function to create the form when called, I do not kill GH when I close things...

Now to my issue. Somehow I thought the output variables (A for example) was able to be seen by all aspects of my code. What I want to do is click a button and have A change values. I got a badly working version by declaring a variable and in the button event handler changing the value of that variable. Then I am able to set the function equal to that variable, and eventually 'A' can be set equal to that function.

During the execution of the form, A does not dynamically change as I click the buttons. Only if I close and run the form again do I see the output of A change. How can I set this up so things update as I click the buttons?

Attachments:

hk_gui1.ghx, 25 KB

Replies to This Discussion

Permalink Reply by David Rutten on September 28, 2009 at 8:07pm

Luis,

there is no way this will ever work right. I'm not sure how well I can explain.

Most Desktop applications are based on a single Window (Form). Rhino is such an application, so is Notepad. When the application starts this Form is displayed, and when the form is closed that automatically causes the application to be terminated. You do not want a Form like that, so don't go near Application.Run

What you want is a modeless dialog (a Form that does not hog focus, but instead allows access to the other Forms in the same application), that responds to a button click.

You can make this form through code (like you're doing now) and display it on screen using form1.Show()

If you use form1.ShowDialog() instead, the form will be displayed as a modal dialog and you will not be able to "reach" either Grasshopper or Rhino while the Form is visible.

The big problem you have is that your form is created inside a function (the RunScript() function inside your VB component), and it's only possible to add data to the output while this function is running. However, since you're creating a modeless dialog, the window is displayed and execution of the Grasshopper solver immediately continues. Probably by the time your form1 has managed to paint itself onto your screen, Grasshopper has already moved on to the next component that needs solving.

What you need to make this work is control over the Grasshopper solver routines. You have to cause your VB component to "expire", and then you have to tell Grasshopper to start a new solution, so that your RunScript function will be called again.

There are a number of things you can do, but for this to work properly you need to free yourself from the constraints imposed by the Scripting component. I'll try and type up an example though...

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by David Rutten on September 28, 2009 at 9:11pm

Well, it's a nasty hack for sure. Also, making Windows through code is a massive pain in the *ss.

Note, when the next version of Grasshopper is released this will no longer work :)

--
David Rutten
david@mcneel.com
Seattle, WA

Attachments:

CreateADirtyDialog.ghx, 22 KB

Permalink Reply by Damien Alomar on September 28, 2009 at 10:24pm

I'm sure its nasty, but it does have some juicy tidbits with it...mmm... ActiveDefinition.NewSolution(True)...that will still work with the new version, right? :)

BTW, will a new version be out before Chicago/NY/London? No worries if it won't.

Permalink Reply by David Rutten on September 28, 2009 at 10:40pm

No, that's exactly the bit that won't. The new version no longer has a single active document. I need to get rid of this top-down approach if clusters are going be definitions-inside-definitions.

At any rate, calling Definition.NewSolution(True) is a disgusting way to refresh since it recalculates everythying everywhere. What I can do in future versions of the VB and C# components is provide access to the parent component inside the RunScript function.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by David Rutten on September 28, 2009 at 10:41pm

Also, the next version will have different names for all classes. I've finally replaced the "EH_" prefix with "GH_". Explicit History is -at last- utterly and completely extinct.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Luis Fraguada on September 29, 2009 at 12:22am

David,
Thank you for explaining and taking the time to cook that up. Fortunately, the definition this is supposed to run is not so heavy so maybe it will be ok.

Good to hear you are cleaning out the cruft and reworking clusters. Looking forward to future revisions (p.s. not stopping in Barcelona for your world tour? There are cañas and tapas awaiting you!).

If I might make a suggestion (which I have a feeling you wont like ;) ) ... make a Remote Control panel designer in order to customize the Remote Control...this is kind of why I am making this project...this will be for a situation where a GH model will be on display and people are to interact with it.
Anyways, that is probably not a high priority (its not for me anyways) but I am sure when things are ironed out, a little more control over the RC panel would be cool.
Again, many thanks!
luis

Permalink Reply by David Rutten on September 29, 2009 at 12:51am

These are the features I'm adding to the Remote Control panel for the next release:

1) Items on the panel can be grouped in collapsable containers. Containers can be re-ordered by click+dragging them around.

2) Containers can have custom names and custom colours.

3) Items can be re-ordered inside containers or moved between containers by click+dragging.

4) You can specifically include/exclude items from the Remote Panel. Eventually (though probably not at first) the Remote Panel will support Sliders, Toggles, Number and Integers parameters, String parameters, Colour parameters, Swatches, Graphs, Gradients, Text panels and whatever makes sense. But probably only a few of these types will be added automatically, I haven't decided on that yet.

5) There will also be a way to add custom comments to panels.

I'll probably have to introduce a working mode and an editing mode otherwise the sheer amount of possible things that can happen due to a single click+drag would be very confusing indeed.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Luis Fraguada on September 29, 2009 at 12:55am

You can specifically include/exclude items from the Remote Panel. Eventually (though probably not at first) the Remote Panel will support Sliders, Toggles, Number and Integers parameters, String parameters, Colour parameters, Swatches, Graphs, Gradients, Text panels and whatever makes sense. But probably only a few of these types will be added automatically, I haven't decided on that yet.

ImageSampler ;)

Cool, it sounds like that would be quite a change from the RC panel of old! Looking forward to the work you guys have done in Seattle! Thanks

Permalink Reply by Luis Fraguada on September 29, 2009 at 10:24am

David,
Keeping in mind your warnings of future compatibility, I just wanted to post this example. I feel almost disgusting that I went there (for sheer redundancy), but I did go there...this example has a trackbar (slider) :(

Anyways, the trackbar works :)

My version has an issue which your version solved with a slider (in GH...oh boy) which is when I close the Form and set the activate switch to False, if I switch back to true, it complains about the text box and not being able to access it because it has been disposed. This resets if I make an edit to the code in the component.

Any way to avoid this? Meaning, if I close it or set activate to false, when I set it to true a new form appears (but not duplicate).

p.s. default windows form graphics are hard to swallow...

Attachments:

vbGUI_sm_01.ghx, 27 KB

Permalink Reply by Damien Alomar on September 29, 2009 at 7:47am

Hmmm... Clusters are moving to a "definition inside definition" model. This sounds really cool, and depending on how its implemented, almost seams GC like. Putting in access to the parent component from the scripting components sounds cool, but the reason I was so intrigued by recalculating the new solution was as a way to update the definition from outside the GH environment. This has been something that I've been wondering about for a while, with this looking as though its the "best" way to do it.

I guess what would be a "better" solution would be to be able to expire individual components. Scrolling through Intellisense, it seamed as though there might be a few options for this, but nothing that jumped out at me. Again, since the issue is really updating from outside of GH, I would imagine that there isn't enough public access to those methods/functions (as well there shouldn't be).

Long and short, I think things a ripe for an actual SDK (or better yet, just making certain parts "public"). The GH community has been lucky enough to have people like Luis, Andy, and Giulio really push the limits of what can be done with a scripting component, and I think a full SDK could provide easier access to all the other things that are trying to connect to GH....Just a thought.

Permalink Reply by David Rutten on September 29, 2009 at 10:59am

The SDK is quite flexible. I've been adding xml comments to many classes and functions so intellisense should provide ample information in tooltips about what certain members and methods are for.

The problem with any SDK is not how it's implemented, but how you access the running instance. It's easy enough to make a Project in Visual Studio that references Grasshopper.dll, but how do you make sure that when you start your app, you'll tap into the Grasshoper.dll which is currently running inside a specific Rhino instance?

If you're a component developer, there's no problem because grasshopper will load your code instead of vice versa, but access to Grasshopper from the outside will be tricky if not currently impossible.

--
David Rutten
david@mcneel.com
Seattle, WA

Permalink Reply by Luis Fraguada on September 30, 2009 at 12:14am

David,
What if the app you create actually opens Rhino and calls GH? You should be able to control which Rhino/GH is being controlled no?