Rhino.Display.CustomDisplay class clearing

Hello,

I have been playing around with the code from this thread on the CustomDisplay Class.

My code is as follows:

private void RunScript(List<Curve> crv, Color c, int w, bool active, ref object A)
{
    //your code here…

    if (m_display == null)
      m_display = new Rhino.Display.CustomDisplay(true);

    m_display.Clear();

    for(int i = 0; i < crv.Count; i++){
      m_display.AddCurve(crv[i], c, w);
    }

if(!active)
    {
      m_display.Clear();
    }

}

//<Custom additional code>
private Rhino.Display.CustomDisplay m_display;
//</Custom additional code>

It seems I have a similar issue as was explained in the post I linked to above. If I toggle the 'active' boolean, I can clear (when false) and have the display redraw when I set it to true. What I do not get is why the call to m_display.Clear(); after the initial conditional statement in the RunScript method is not automatically clearing the display? Everytime I edit the script, I get the remnants of the last display that I had.

I suppose that m_display is null after I edit the script, thus I get a new instance of the CustomDisplay. Kind of a chicken/egg scenario. The solution I am thinking of in my mind does not seem appropriate. (Can GH know when I am entering to edit the script, and if so, can it very nicely clear the CustomDisplay classes that are in memory)...

I can think of situations (in a Custom Component for example) where this might be easier to resolve since one is not entering in there to edit things. When the component is disposed, so can the Custom Display be cleared... but just wanted to know if it is possible through a scripted component...

Thx!

Luis

p.s. on Rhino Version 5.0 (5.1.2012.110, 1/10/2012), GH 080065 + Script.gha hotfix

Replies to This Discussion

Permalink Reply by Damien Alomar on January 13, 2012 at 8:53pm

The problem here is really the recompile of the script that's needed everytime you edit the component. That old display class basically gets thrown away without being properly disposed, which is causing those remnants to stay there. I do think that the best way would probably be to have the instance of the custom display be "owned" by code that would has a longer life time than a component (ie a standalone dll that you reference or a custom component). However, you can add a destructor to the script instance class and take care of disposing the custom display yourself. You'd still be getting a new one each recompile, but at least the old one wouldn't be in limbo...

// Custom additional code // Add destructor to tear down the display... ~Script_Instance (){ // Just a tracing statement... Rhino.RhinoApp.WriteLine("Destructing Script Instance of {0} @ {1}", this.GetHashCode(), DateTime.Now.ToString("HH:mm:ss.fff")); // Dispose of the custom display... myCustomDisplayInstance.Dispose(); }

RSS