Control Knobs in C# ...?

Replies to This Discussion

Permalink Reply by David Rutten on October 9, 2015 at 7:59am

Yup, the dial exposes all kinds of properties, Minimum, Maximum, Value, Range, etc. etc.

There's also a RepairValue() method which ensures the current value doesn't violate limits and decimals. When you're done adjusting the dial, be sure to call ExpireSolution() on it, otherwise the new settings will go unnoticed.

Permalink Reply by Riccardo Majewski on October 9, 2015 at 9:01am

That's... that method can work "during" the solution?

I wanted to do something like this:

http://www.grasshopper3d.com/forum/topics/program-constraint?commen...

To do:

- Button to reset the knob value to 0;

- max-min values used to make the knob "loopable"

  example: min-max 0°-360° ...when, with the cursor, i go from 359 to 1 ,

  there are 2 possible ways: value not limited > 361 , value limited to 360 and i must go back

  "manually"

  by c# script i could make it loop with values keeped inside min-max while spinning the knob

  without limitation

Maybe it sounds stupid, but i often have to make this with components and the value written on the knob is not what i'm using in the definition...

Would it be ever possible?

Permalink Reply by Riccardo Majewski on October 9, 2015 at 9:44am

Something like this.... more or less...

Permalink Reply by David Rutten on October 9, 2015 at 11:27am

You cannot change a dial during a solution, because that means it will expire objects which may already have been solved during that solution and Grasshopper doesn't know how to deal with that.

The code that sets the value of a dial needs to run outside of solutions. One example of such code is code that is invoked by UI event handlers such as MouseDown, MouseMove or KeyDown. However in order to handle these you need to actually provide your own UI, which is not possible through script components (I mean specifically custom UI on the canvas, you can make windows and buttons via the script components that exist as separate entities to the GH window).

Another way to do this is to trigger a new solution and update the dial in the events/callbacks that happen before a solution starts.

Permalink Reply by Riccardo Majewski on October 11, 2015 at 4:48pm

But then... how its possible with slider? In the definition I linked it is working, don't it??

The attached file would work, if just knob element in c# had all the properties like sliders.

(now it isn't working because the mouse cursor "pull" the slider out of the extreme, in a knob it would simply start a new cycle around but with value resetted...)

What you exactly mean with "expire"? I've tried that c# stuff for sliders, the rest of the definition follow it problems like i'm manually setting 4 sliders simultaneously....

Attachments:

• slider_example.gh, 9 KB

Permalink Reply by David Rutten on October 12, 2015 at 6:56am

I'm confused about exactly what objects are supposed to affect what other objects, but I attached a C# script which copies all settings from one slider to a similarly named dial when a button is pressed.

Attachments:

• slider_example.gh, 5 KB

Permalink Reply by Riccardo Majewski on October 12, 2015 at 9:08am

Thanks again David.

By reading your definition i managed somehow to finish what i wanted.

(almost perfect)

Still, i don't get what "expire" stuff is all about.... but hey it's working as intended now!

Thanks again.

Attachments:

• knob_limiter_looper.gh, 9 KB

Permalink Reply by David Rutten on October 12, 2015 at 9:51am

Expiration is what happens when a file is changed. For example you can drag a slider using the mouse. This mouse event causes the current slider value to become stale and the slider to expire. However any object which is connected to the slider is now also stale and also expires. And any object connected to those objects is now stale.

So every time a change is made (slider drag, wire connection added, Graft option enabled, component disabled, etc. etc.) it causes the object which was changed to expire and all objects that in some way depend on that prime object to expire. This wave of expiration events just erases the currently cached data on the affected objects and does nothing else.

Almost always an expiration wave is followed immediately by a new solution (to see what happens when this isn't the case, lock the solver and then make a change, you'll see all expired objects turn orange). A solution collects all expired objects, puts them in a list and then solves each object in that list. That is why expiring new objects during a solution is not allowed, because that might either expire objects that were never on the list to begin with, or it might expire objects which have already been solved during this solution and therefore won't be considered again.*

If you change an object through code, you're typically in charge of expiring it as well, only a few very high level methods do that for you. You may also need to record an undo event, as that doesn't happen automatically.

* I'm trying to make this a little more flexible in GH2, making it possible to expire stuff during solutions. However a big problem here is that you might end up with an infinite loop of expirations/recomputation steps. Also no guarantees, this is merely something I'd like to do, it doesn't work yet.