GOOP4 Kernal bug

[MaxV]

I found a bug in the GOOP4 kernal VIs. It is the same type of one I found in _goop4.llb\GOOP4_CreateObjectDvrReference.vi for LV2013 (you know Micke) but this time it's in _goop4.llb\GOOP4_GetClassObjects.vi.

The extracting of the class name don't work for clones (the clone numbering changed with LV2013).

It now looks like in Wrong.png

my solution is in like Better.png

/Max

[MikaelH]

I don't think this will work for Classes in libraries, will it?

[MikaelH]

I thought the number 6 would fix the clone issue, I tested it and it looks like it works.

Can you send me an example where I can see the problem?

[MaxV]

Do you mean llb with libraries? I haven't tried that. It will probably not work.

[MaxV]

No I think  the number 6 is the old implementation and when they changed to  6 digit clone number it was not enough.

We found the problem in a class that use re-usable objects (to save creation time)

Make a class (persistant) that has an attribute flag to tell if its free or not.

Add a metod Free that sets the flag to FREE.

In the create metod befor calling new use the GetClassObjects.vi to find other objects, check for the first FREE.

If found, use it and set the flag to BUSY, if not found use new as normal.

To test, create a number of objects, then Free them (not Destroy). Run this a couple of times and you should not get an increasing number of objects in memory, the objects shall be reused. If the GetClassObjects.vi is flawed this will not work.

[MikaelH]

Okay, it's added on the todo list:

https://github.com/opengds/OpenGDS/issues/4

Max, I'll try to have a fix out by the end of the week.

//Mike

[MikaelHolmstrom]

I've created this pattern (Feather Weight) as well.

But I didn't use the GetObjectStatus, instead I added ClassAttribute support to the class.

There I save all created objects, I think that will be more efficient.

[MikaelH]

Max, can you try my changing the number 6 to number 7, will that do it?

[MikaelH]

Max, if you like to test the nightly build you can find it here:

OpenGDS 1.0.11(Master) LV2012-32
OpenGDS 1.0.11(Master) LV2012-64
OpenGDS 1.0.11(Master) LV2013-32
OpenGDS 1.0.11(Master) LV2013-64
OpenGDS 1.0.11(Master) LV2014-32
OpenGDS 1.0.11(Master) LV2014-64

It finds the class name in a different way. BTW It's not been tested yet.

I'll do some other minor fixes before officially releasing th next version of OpenGDS.