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).
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.
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.
Try with a button (or double click event) to enable/disable the MouseCallback before making changes in code.
Ideally the C#/VB components would have overridable methods that are called when the code is about to be retired, but for the time being Daniel's suggestion is indeed the best one for stuff like this.
In general it would be nice to be able to suspend updates like this, not just for coding purposes.
like to use any static fields, since they are shared amongst all the instances of this script.
Isn't the autogenerated Script_Instance class a singleton? Every time you edit the code it creates a new different type with a single instance.
Still I agree, the reason for using static fields was for laziness (not as in delaying execution to when need, but as in me being lazy). I also want to apologize for the horrible misuse of access modifiers. Never had to maintain a large code base 4 years ago, now I appreciate the value of good coding practices a lot more.