algorithmic modeling for Rhino
What does 'not work anymore' mean? Is there an error message? A crash? It works here as far as I can tell.
At any rate, there were several weird decisions made in your code, the attached works for me:
I didn't like to use any static fields, since they are shared amongst all the instances of this script. And it should really only be per script. I also stopped the RunScript method from creating new feedbacks all the time, although still if you change the code now, there will be two feedback instances both running. If you change the code again, there will be three ad infinitum. It would probably be a good idea to restart Rhino after every few changes to this script.
I added a MouseFeedbackData type so it's easier to share specific values amongst different classes (this gets around the not-using-static difference).
In my opinion events in script components are really dangerous and are potential memory leaks, but its an interesting solution, thank you.
Wouldn't it a much better solution to write a separate program observing mouse input and only invoke the change in a custom component; or even more simple by streaming to a common file, which constantly could be read by a script component?
.. or better, by retrieving it lowlevel:
private void RunScript(object x, object y, ref object A)
A = GetCursorPosition();
// <Custom additional code>
/// Struct representing a point.
public struct POINT
public int X;
public int Y;
public static implicit operator Point2d(POINT point)
return new Point2d(point.X, point.Y);
/// Retrieves the cursor's position, in screen coordinates.
/// <see>See MSDN documentation for further information.</see>
public static extern bool GetCursorPos(out POINT lpPoint);
public static Point2d GetCursorPosition()
//bool success = User32.GetCursorPos(out lpPoint);
// if (!success)
Unless there's a demonstrable problem with using the RhinoCommon classes, I'd really hesitate to switch to an approach which probably doesn't work on all versions of Windows and certainly won't work on the Mac and may have all sorts of weird side-effects on virtual machines.
mousehandling within grasshopper is problematic per se...
The problem with the rc approach is that it needs an event/callback, which again is a problematic within scriptcomponents. As I wrote, an separate running piece of code within a custom component may solve the problem, but for scripting its a rather bad idea to use an event instead, as you already pointed out why.
Sure its no platform friendly approach, its obvious why, but seriously I don't get that mac or win 95 compatibility issues. There is a tremendous amount on energy spend on multiplatform functionality, but while 3rd party, high quality tools are going to break away from rhino, only few effort is done to replace them. As far as I know, most professional industries do work with window, simply because most cad apps only work for this platform. I mean there might be also an mac specific low level approach, but shouldn't we focus more on better functionality rather then making it good for everyone.
I for myself can't think of any practical use of mouseinput within grasshopper, without changing the concept of grasshopper as a whole. So who cares....
Well one thing you can do is not call ExpireSolution(true) directly from within the event, but to aggregate the events and only respond after a delay using a timer.
That'll allow you to buffer stuff for as long as you want. Either limit updates to X times per second, or maybe only trigger an update if the mouse remains stationary for more than N milliseconds, or...
No practical use of mouse input within Grasshopper? How do you reference geometry? :P
I would say Grasshopper not being more integrated with the viewport (and responding to things like selecting objects, moving the camera, etc.) is a feature Grasshopper noticeably lacks, rather than something Grasshopper is not made out for.
But yes, the current way scripting components work is bad for subscribing to events, or other stuff that require state to persist outside the scripting component. I'm sure there are good plans to improve on this for Grasshopper 2 (and hopefully be able use an external editor for scripting and debugging).
It would be better to use user32.dll.
Mouse_Move using user32.dll without timer!
It lokks like that restarting Rhino is the only way to solve the problem!
It would probably much better to use Tom's code attched below.