update solution when rhino units change

Replies to This Discussion

Permalink Reply by David Rutten on January 14, 2012 at 1:51am

There is no specific event for this, but you can handle the generic document properties change.

Public Sub New()

  MyBase.New(...)

  AddHandler Rhino.RhinoDoc.DocumentPropertiesChanged, AddressOf DocumentPropertiesChanged

end Sub

Private Sub DocumentPropertiesChanged(ByVal sender As Object, ByVal e As Rhino.DocumentEventArgs)
   If (e.Document.ModelUnitSystem <> cachedUnitSystem) Then
    cachedUnitSystem = e.Document.ModelUnitSystem
    ExpireSolution(True)
  End If
End Sub

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Brian Harms on January 14, 2012 at 8:46pm

Thanks david.

Reason I ask is because internalised geometry does not scale automatically with unit changes in rhino. Is it possible to change this?

Permalink Reply by Brian Harms on January 14, 2012 at 9:05pm

Actually a "scale with rhino units" toggle would be awesome.

Permalink Reply by David Rutten on January 15, 2012 at 2:38am

I'd rather not make it automatic, that's going to annoy people. Since (I'm wildly guessing) this doesn't happen all that often and when it happens people know it happens (after all, they just changed the units didn't they?), would it be ok if this was an action in the Solution menu? Something like:

Solution:

• Recompute
• Disable Solver
• Clear Exception Ignore List
• Upgrade Legacy Components
• Remap Internal Geometry (mm -> m)
• ...

It would involve storing the unit kind on the ghx document, but that's not a big problem.

--

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Hannes Löschke on January 15, 2012 at 2:48am

With components such as Karamba and GECO relying on physical units, it would be great to ensure integrity of units over different Rhino files.

Knowing is way better than guessing the original documents intented scale.

Permalink Reply by Brian Harms on January 15, 2012 at 12:15pm

I think it would be best as an option to toggle as opposed to a one-time action, but placing it in the solution menu would be just fine.

The real issue is with people starting new rhino files with different units than the internalized geometry was created with (not so much changing the units after the file has been created - although that could be a small problem as well and I'm trying to cover my bases).

What do you think?

Permalink Reply by Brian Harms on January 15, 2012 at 12:54pm

Hey David, I finally got a chance to put your code in GH and I just realized it's in VB... is there any chance you could post the C# equivilent? I've been trying to convert it but I keep getting errors.

Thanks again,

-Brian

Permalink Reply by Giulio Piacentino on January 15, 2012 at 1:37pm

Hi Brian,

This is the equivalent code in C# to what David posted.
There is nothing handling event removal, so in this state it will leak memory preventing the object from being disposed. You should remember to handle that case, too.

public class MyClass
{
   public MyClass() //constructor
   {
      Rhino.RhinoDoc.DocumentPropertiesChanged += DocumentPropertiesChanged;
   }

    private void DocumentPropertiesChanged(object s, Rhino.DocumentEventArgs e)
   {
      if (e.Document.ModelUnitSystem != cachedUnitSystem)
      {
        cachedUnitSystem = e.Document.ModelUnitSystem;
        ExpireSolution(true);
      }
   }
}

Thanks,

- Giulio
________________
giulio@mcneel.com

Permalink Reply by Brian Harms on January 16, 2012 at 6:16pm

Hey Giulio, thanks for the reply.

So I've been trying to get this working within a C# component alongside the code I started with, which is:

private void RunScript(System.Object , ref object Units)
{

Units = doc.GetUnitSystemName(true, true, true, true);

}

Which I've been trying to ExpireSolution to get it to update. I understand what's happening in the code, but not being so experienced I've run into a few road blocks.

Do I need to create a new instance of MyClass to run the conditional that will expire the solution, or will it happen without doing so? I'm also not sure where to place the original code within this new code.

My guess was that the creation of MyClass would go in the additional custom code section, and I would create an instance of the class in the main private runscript section which would include the code to return the current units as well as the method to ExpireSolution. Is this even close? 

I guess my very basic question is how to merge the code I've pasted above with david/Giulio's C# code within a C# script component so that it will still output mm, in, cm, etc.

thanks for all your help,

-Brian

Permalink Reply by Giulio Piacentino on January 17, 2012 at 2:12am

Hey again Brian,

if you are adding this to a scripting component, then MyClass is called Script_Instance. This is the class on which you could add the code. Basically, you put the code into the second block, without the class scope.

Here is a sample. The previous warning about the fact that the component written like this will never be disposed is still valid...

I hope this helps,

- Giulio
______________
giulio@mcneel.com

Attachments:

• units.gh, 2 KB

Permalink Reply by Brian Harms on January 17, 2012 at 11:47am

Hey Giulio, thanks so much for your time, that's exactly what I was trying to do.

So is there any way to avoid leaking memory while still achieving this result? Will the leaking of memory adversely affect the (noticeable) performance of the rest of the definition?

I had read a post by David regarding the .net garbage collector and I was under the impression that those memory leaks would be cleaned up automatically, but since for the most part I don't know what I'm talking about there's a good chance that's not the case.

thanks again,

-Brian