Parent doesn't have a valid document

Dear all,

I have an interesting problem that occurs since the recent 0.9.0051 release on some components I am developing.

I would like to create and store a component in a private field that gets removed in a later call to SolveInstance. Whilst the code previously worked in previous versions, I seem to be getting a component exception thrown: "parent doesn't have a valid document". It still goes on to remove the component, so I know I'm getting the canvas correctly and my component is being picked up.

Here's what happens:

I suspect the latest release must 'do' something to the document objects after SolveInstance has finished doing its business, but I'm not quite sure what and I've spent most of today struggling to resolve it.

Here is a code snippet from the class:

private GH_Component myComponent;

protected override void SolveInstance(IGH_DataAccess DA)
{
// Get data
bool token = false;
DA.GetData(0, ref token);

// Make a new component instance
if (!token)
{
// Get a 'construct point' component from its guid
myComponent = (GH_Component)Instances.ComponentServer.EmitObject(new Guid("3581f42a-9592-4549-bd6b-1c0fc39d067b"));

// Add the component to the canvas
OnPingDocument().AddObject(myComponent, false);
myComponent.Attributes.Pivot = new PointF(200, 200);
}

// Delete the stored component
else
{
OnPingDocument().RemoveObject(myComponent, false);
return;

}

I wonder if anyone is having the same problem, although I suspect this may a question for you David - sorry!

Find attached.

Many thanks,

John.

Attachments:

Jimmy.cs, 2 KB

Replies to This Discussion

Permalink Reply by David Rutten on May 9, 2013 at 3:52pm

The exception is thrown inside the solver of [Construct Point]. It really is illegal to modify the state of a document during a solution; adding/removing wires, parameters or objects or changing access types of parameters are all things that should not be happening. The current SDK is pretty lackadaisical about enforcing these rules, which is probably why you've been getting away with this so far.

You need to find a way to either run that code outside of a solution, for example from a mouse-event, or add these objects to a different document you're maintaining. I'm not entirely sure why you're adding/removing components so it may not make sense to use a separate document.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by John Harding on May 18, 2013 at 6:38am

Thanks for the explanation David.

A while ago, I thought it would be kind of interesting to write a component that generated grasshopper definitions from scratch automatically, kind of like genetic programming for grasshopper. This set of components is now called Embryo and almost ready for (potential) release. The early versions of this worked by generating networks on a separate document.

The main reason I switched to adding and removing components/wires on the same document was firstly so that I could integrate optimisation components such as Galapagos (and now Octopus), and secondly for a better transition between existing definitions and generated ones. For example, to enable existing parameters to be included in any newly generated network, as well as retrieving generated data back to a permanent network.

If it's ok with you, I will send an email with the Embryo gha and some examples which run on 0.9.0014. This will give a better picture of what I'm trying to achieve. Perhaps these components are just a bit too naughty, although I hope not :) Either way, it's probably best I show you how I'm looking to use grasshopper before I release any components.

John.

Permalink Reply by David Rutten on May 18, 2013 at 9:49am

Would it not be possible to change your code so that the component+wire additional/removal happens outside of a solution? You could for example handle the SolutionStart event on GH_Document or maybe schedule a solution with a callback delegate?

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by John Harding on May 20, 2013 at 8:52am

Yes, thanks for the pointer. Got it working by adding a handler to the SolutionStart event. Next step is to see what happens when the solvers are incorporated (hopefully not bad things).
Code attached for reference (does something slightly different than before).

John.

Attachments: