How to replace CustomCurveObject within a Custom Grips Plugin?

[pagarcia]

Hello,

I’m writing a RhinoCommon custom grips plugin similar to Dale’s SampleCsRectangleGrips, but instead of getting a rectangle polyline as input I take a CustomCurveObject (similar to Dale’s SampleCsCustomLineObject).

I have a problem in overriding the GeometryBase NewGeometry() method inside CustomObjectGrips: every time I drag a grip, I do not only want to get in return a new polyline geometry for my curve, but I want the method to replace the instance of my CustomCurveObject.

In other words, instead of having inside NewGeometry() something like return new Polyline(m_active_rectangle), I would like to have return new SampleCsCustomLineObject(m_active_rectangle), my new type of CustomCurveObject.

I tried, but I got the error "Cannot implicitly convert type SampleCustomLineObject to Rhino.Geometry.GeometryBase".
I thought it would be great to access Rhino.DocObjects.Tables.ObjectTable from here and call to Replace this Rhino Object, but I don’t know how to reference my input custom curve from here.

Many thanks!

[dale (Dale Fugier)]

Hi Pablo,

I do not only want to get in return a new polyline geometry for my curve…

That is the way Rhino’s grip handler works - sorry. If you want it to work differently, then you may have to come up with your own grip mechanism.

– Dale

[pagarcia]

Hi Dale,

Ohh, I see. I will then try to create my own grips class with an array of points, and put everything together inside OnDraw() in my CustomCurveObject.

Thank you!
Pablo

[rgr]

Hi @dale,

is there a way to reliably get the curve NewGeometry() returns?

Edit: to clarify, I want to use the returned curve to create a new object(which takes a curve as an input) instead of having to come up with my own grip class.

[dale (Dale Fugier)]

I want to use the returned curve to create a new objec

I’m not sure I follow. Can you try to explain a little about what you want to do?

– Dale

[rgr]

I have a command which creates a closed curve + hatch + dimensions by offsets a guide curve. I save all the geometry in a block and attach the guide curve as userdata. From the guide curve, I create custom grips to handle manipulaition.
If I could access the curve created from NewGeometry(), I would have a reliable result to recreate the block over and over again.

Currently, I have a workaround (not shown) using the RhinoDoc.AddRhinoObject event but I’m concerned it might not be 100% reliable in filtering out unwanted geometry.

[dale (Dale Fugier)]

Hi @rgr,

One thought, based on your video, to had History to your command. That way, when the object is edited outside your control, you can re-run the calculation. There are a couple of sample commands in the developer samples repo on GitHub that implement history.

Also, a grip handler is just a custom class. There isn’t any reason you couldn’t move the curve calculation code from your custom grip handler into a more generalized class that is used by both your grip handler and some other tool.

Make sense?

– Dale

[rgr]

Hi @dale,

Thank you for your answer, that does sound like there is a way to solve it, I’ll look into it and see if I can come up with something. Thank you again.

[pagarcia]

Hi @rgr,

I found a solution for this by attaching user data to my geometry in the custom grips class NewGeometry(). The Rhino geometry is then converted to my custom geometry during copy/paste/load events by vtable modification.
From what I see in your video, I’d override Draw() in both your custom object and custom grips to draw the annotation marks, most probably through a conduit.

Here an insightful quote by Dale about this topic and two related threads:
(Alternative to C++ vtable modification to promote objects on document load)
(Copy pasting custom rhino mesh object subclasses)

Alternative to C++ vtable modification to promote objects on document load

First, Rhino does not allow for a true custom object. If we did, would be possible to distribute 3dm files that others could not open without your plug-in.

However, you are allowed to derive classes from our run-time object classes, such as CRhinoPointObject , CRhinoCurveObject , CRhinoBrepObject , etc. and override any virtual members you want.

If your derived class has additional data, then for this data to persist it must be store as user data using a class that derives from ON_UserData . The reason for this is that custom objects do not serialize - Rhino will only serialize Rhino objects. By storing your data as user data on the object, your custom data will persist.

When reading a 3dm file, again, Rhino only reads Rhino objects. However, when a Rhino object is read, your attached user data will also be read (by your plug-in).

At some point, when the file I/O has completed, you have the opportunity to convert the Rhino object, along with your attached user data, to your own object. One way of doing this is by using the vtable slight-of-hand, which is the most efficient. Another way is to construct one of your objects from the user data and then call CRhinoDoc::ReplaceObject as you’ve mentioned.

[rgr]

Hi @pagarcia

that does sound interesting, but I’m using Rhino Common with c# so it might be not an option. I have to dig into your answer a bit more and learn about vtable modification. Maybe using the Moose ( https://github.com/dalefugier/Moose ) to build the functionality in C++ and call it from the c# plugin is a way.