Grasshopper

algorithmic modeling for Rhino

Hi,everyone!

I have a problem that code in picture_a is work fine,but when i added one line code("public static int i=0".),itwon't work anymore(picture_b)!

What did i miss?

picture_a

picture_b

Code in picture_b does not work because i add "public static int i=0".

Views: 703

Attachments:

Reply to This

Replies to This Discussion

What does 'not work anymore' mean? Is there an error message? A crash? It works here as far as I can tell.

The value of line remains unchanged when the code changes.

when i restart rhino,it works agian!

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).

Attachments:

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>
  /// <summary>
  /// Struct representing a point.
  /// </summary>
  [StructLayout(LayoutKind.Sequential)]
  public struct POINT
  {
    public int X;
    public int Y;

    public static implicit operator Point2d(POINT point)
    {
      return new Point2d(point.X, point.Y);
    }
  }

  /// <summary>
  /// Retrieves the cursor's position, in screen coordinates.
  /// </summary>
  /// <see>See MSDN documentation for further information.</see>
  [DllImport("user32.dll")]
  public static extern bool GetCursorPos(out POINT lpPoint);

  public static Point2d GetCursorPosition()
  {
    POINT lpPoint;
    GetCursorPos(out lpPoint);
    //bool success = User32.GetCursorPos(out lpPoint);
    // if (!success)

    return lpPoint;
  }

Attachments:

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).

Thank you,Tom

It would be better to use user32.dll.

Mouse_Move using user32.dll without timer!

Attachments:

Many thanks,Divid!

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.

RSS

About

Translate

Search

Photos

  • Add Photos
  • View All

© 2019   Created by Scott Davidson.   Powered by

Badges  |  Report an Issue  |  Terms of Service