GHA Developers: Pay attention to Components with SetDataList()

Dear GHA developers,

this is an important message for those of you who have components that output lists of data using DA.SetDataList().

It is important that you make sure you always call SetDataList() from within SolveInstance(), even if you do not have any data to assign. There is some logic in place that will automatically create output data structures, but this logic may result in unexpected and unpredictable (from the user point of view) data when you omit a call to SetDataList(). A typical implementation of SolveInstance() should look something like:

Dim A As SomeData = Nothing

Dim B As SomeData = Nothing

DA.GetData(0, A)

DA.GetData(1, B)

If (A Is Nothing) OrElse (B Is Nothing) OrElse _

(Not A.IsValid) OrElse (Not B.IsValid) Then

DA.SetDataList(0, Nothing)

Return

End If

'Do more stuff here, but always call

'SetDataList() before any Return statements.

DA.SetDataList(0, results)

or, if you're cool:

SomeData A = null;

SomeData B = null;

DA.GetData(0, ref A);

DA.GetData(1, ref B);

if( A == null | B == null | !A.IsValid | !B.IsValid )

{

DA.SetDataList(0, null);

return;

}

//Do more stuff here, but always call

//SetDataList() before any return statements.

DA.SetDataList(0, result);

I'll add a help topic to the SDK documentation explaining this in more detail as well. The logic that invents a reasonable data structure layout for output parameters is being beefed up for 0.9+ and there will be changes to the way it behaves but I realised I cannot actually fix all possible quirks unless SetDataList() is consistently called.

David Rutten

david@mcneel.com

Poprad, Slovakia

Replies to This Discussion

Permalink Reply by Giulio Piacentino on May 2, 2012 at 3:08am

Hi David

could you please review this particular type of SDK breakage?
In this form, it will mean that very many current add-ons will stop working properly, and it will be very difficult to spot the error, because the basic case will still work as usual.

Thanks,

- Giulio
_________________
giulio@mcneel.com

Permalink Reply by Jon Mirtschin on May 2, 2012 at 3:22am

I agree it's a possible source of problems, but my preference is to back David's decisions on best way forward. The SDK is openly stated as being underdevelopment, and past SDK breakages have never taken very long to resolve.

Developers can search their code for occurrences of "SetDataList(" and ensure they revise their code. Otherwise perhaps a total breakage (either renaming the method) or changing the parameters will force this. Are there many other known breakages?

Permalink Reply by Giulio Piacentino on May 2, 2012 at 4:12am

I think I've omitted my results out of this discussion because I am not sure what is best. I was also thinking about some renaming of the method, like you say, to help finding the change; or some other ideas if anyone had some. Please also see my answer to David's statement.

- Giulio
_______________
giulio@mcneel.com

Permalink Reply by Danny Boyes on May 2, 2012 at 3:22am

(from the user point of view)

Would it not be better to try and put the genie back in the bottle as it would seem to be a bug fix for some erroneous path behaviour, rather than let it continue the way it is.

Permalink Reply by Giulio Piacentino on May 2, 2012 at 4:21am

Sure, current overall behavior needs to be fixed. But to help understanding the change, it will be useful somehow to highlight this change to third-party developers. Changing the behavior underneath is great, but it would be great to have some way for developers to know directly of the fundamental change. Please also see my answer to David's statement.

Cheers,

- Giulio
_______________
giulio@mcneel.com

Permalink Reply by David Rutten on May 2, 2012 at 3:35am

Hi Giulio,

it's not a breakage, it's an existing bug that can only be fixed in this way.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Giulio Piacentino on May 2, 2012 at 4:08am

Previously it was possible to omit the call and use the index of the list to fix the location. E.g.: SetDataList(0, list, 2) rather than SetDataList(0, list).

Right now, it is required we do call this method. This is great, as we will all have one less source of bugs. But the function behavior has fundamentally changed.

To let surely people know about this, for example, you could consider renaming the function. This way, old assemblies that used only SetData and SetDataTree will continue working, while SetDataList will need to be referred to the new method.

Just a thought to make this simpler to maintain, not an apology of that bug.

Cheers,

- Giulio
_______________
giulio@mcneel.com

Permalink Reply by David Rutten on May 2, 2012 at 4:25am

No, the function hasn't changed. Nor the signature, nor the behaviour. It will work better than before, but there will still be rare bugs left unless you make sure to always call SetDataList() before returning out of SolveInstance().

Old components will work better than before (well, should work better....), but there is one bug I cannot fix without breaking the SDK in quite a substantial fashion.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Danny Boyes on May 2, 2012 at 4:36am

I think this is an answer to me of a post that got deleted just after I posted it. Sorry!

...

The bug you speak of is that the Nulls up 1 branch level bug?

Permalink Reply by David Rutten on May 2, 2012 at 5:01am

Yes, that was one incarnation of the underlying bug. There were 3 others I could work out, maybe more.

David Rutten

david@mcneel.com

Poprad, Slovakia

Permalink Reply by Giulio Piacentino on May 2, 2012 at 4:42am

Thanks for this further explanation, David. I understand what you mean with working better than before and that this descends from the need to make the code alert you about the one-level-more-down branch before it exits.

- Giulio
_______________
giulio@mcneel.com

Permalink Reply by Suryansh Chandra on May 2, 2012 at 8:05am

I'm a bit confused here:

If you're bailing out instead of finishing cleanly (due to something going wrong, null ref, whatever), would you still have to call SetDataList if in a good scenario (where everything works) you were outputting a list? Can't you just call DA.SetData(x, null)? How would it differ?

What I mean to ask in code is:

SomeData A = null;

SomeData B = null;

DA.GetData(0, ref A);

DA.GetData(1, ref B);

if( A == null | B == null | !A.IsValid | !B.IsValid )

{

DA.SetData(0, null);

return;

}

DA.SetDataList(0, result);