C# sliders that contol sliders that ...

Replies to This Discussion

Permalink Reply by Arend on December 10, 2014 at 5:28pm

Hi Peter,

The group solution is not really my preference, but it works. I chose the solution because it scales (scaled?). (I don't need to change any code to change any behavior, but still, it's a hack.. Something to do with getting hit on the head a lot with DRY and SoC.)

You've opened a nice can of worms. Problems with events inside C# blocks is that a C# block contains an instance: Script_Instance. Usually, this has only a connection to it's owner, a ScriptComponent, and if the script component is recompiled, the Script_Instance is destroyed, and a new one is created.

This stuff all changes once you start tying events to a Script_Instance method. Basically what happens is that a new Script_Instance is created, and if you don't watch out, all events are still pointing to the previously compiled Script_Instance (yay!). Now you've got yourself two Script_Instances pointing to the same Script Component. One (or multiple) which are very unlikely to die, unless you really tell it to do so.

So, when using events, you really need to do your bookkeeping, and keep it together, or there will be lots of events lying around, and a big mess is ensured. That's where the SliderListener class comes in.

This little class will be your accountant, and keeps track of which sliders it's tracking, and remove the event listeners once it senses that something is not really honky-dory. 

All you have to do is to create a callback to what the master should tell to it's slave. Right now I've added three options: one to reset the slider, and one to set it to the value of the master, but you should be able to include all the trickery you've used in C#.

Then a little note about selecting sliders:

I've found this to be an effective way to select sliders (I've grown quite fond of LINQ, this stuff really speeds up all kinds of stuff what would take you lots of loops and ifs)

    private List<Grasshopper.Kernel.Special.GH_NumberSlider> FindSlidersThatStartWithName(string name)
    {
      return this.owner.OnPingDocument()
        .Objects
        .OfType<Grasshopper.Kernel.Special.GH_NumberSlider>()
        .Where(obj => obj.NickName.StartsWith(name))
        .ToList();
    }

Since you're into interactivity, and really much better interactivity can sometimes be achieved using the keyboard, I've included this workflow I've been using this week to speed things up a little bit:

There's a plugin called the GamePad, it's just a simple form that can listen to keyboard events. These keyboard events you can use to manipulate sliders. Combine the master slave, with the keyboard thingy, you can get some funky fast results. (double click the component to get the slider). You can use the up and down arrows to modify the first slider, and left and right to modify the others. Use the R to reset to a default value.

So far, so good. I think there's a good collection of hacks lying around here.

Anyway, I'm still not sure about this workflow. I've found the method of adding a listener to the SolutionEnd event of the GH_Document to be the most reliable way of adding methods that will modify data/sliders/etc, but it still feels quite strange, is there a nicer way to do this? (David, Guilio?)

Attachments:

• Sider_Control_V3-AVW.gh, 14 KB
• GameTools.gha, 8 KB

Permalink Reply by peter fotiadis on December 11, 2014 at 12:45am

Hi Arend,

1. Thanks a lot (I.Mast.Study.Events.Better)

2. I've forwarded your answer to auntie D. She said: listen to that man.

3. Other than our common "mod/create stuff in collections on a per item basis" problem ... all of a sudden  - quite recently - a girl posted the MITESIGF (Most Important Thread Even Seen In Grasshopper Forums). She doesn't even realized that: she's novice:

http://www.grasshopper3d.com/forum/topics/array-1

4. Why this MITESIGF is MITESIGF? For 2 reasons:

4.a: Wooden pairs (Beams) Profile Curves (belonging in some tree) MUST allow individual control on a per  "item basis" (OK, that's obvious) - see Images posted in the thread. No attractor (or any other "global" policy) can cut the mustard here (to tell you the truth this happens in 99% of pure engineering cases, but they appear very rarely in GH Forums - if at all, mind). If the profile curves are defined with 5 points (or 9 for the double thing) we need "on-the-fly" control over this Array (like the radii in your Sphere Manipulator) :

4.b: Critical Bottom-to-Top issues arise: Create a "global" topology (call it "parent") - the beams - and then place real-life "components" (call them "childs") that affect (most probably) the "parent". OK, that's impossible to do with GH/Rhino (peace of cake with CATIA/Microstation) but you can "approximate" things up to a point. Alternatively:  you can "trigger" some interest from GH/Rhino developers if they have any AEC market(s) in mind.

Topic 4.a requires the master-to-slave slider thingy (iterate over branches (index slider:master) > reset the 5 values (value slider:slave) > modify them on the fly > save > increase/decrease branch > ...).

Other than that my definitions are far more challenging than this simple case ... but ... anyway ... long is the path (and hilly).

more soon.

best, The Troll