GOOP/OpenGOOP

[MagicWand]

I finally managed to install OpenGOOP, manually into LV 6... (Some VI was missing, which I found in the OGLIB_String package.)

I know GOOP 1.0 only was a bunch of shift registers, build arrays and such, and was quite slow, but is OpenGOOP faster?

And how is it compaired to GOOP 2.0?

BTW, how is it with OpenGOOP and named objects. I have used that with GOOP, so how do I do that in OpenGOOP?

Another thing I wonder about is: Why is the Default Data Cluster embedded in a VI?

Wouldn't a Default Data Type Definition.ctl do the same job.

The Default Data.vi seems quite obsolete. Why store almost nothing (as in this case) into a VI?

Shouldn't <Class> Data Core Task Enum.ctl be on the front panel of both <Class> Data Core.vi and <Class> Object Data Core.vi? There was no connection to the type def. on FP of one of those VIs, I don't remember which.

[brian175]

I finally managed to install OpenGOOP, manually into LV 6... (Some VI was missing, which I found in the OGLIB_String package.)

I know GOOP 1.0 only was a bunch of shift registers, build arrays and such, and was quite slow, but is OpenGOOP faster?

And how is it compaired to GOOP 2.0?

BTW, how is it with OpenGOOP and named objects.  I have used that with GOOP, so how do I do that in OpenGOOP?

4753[/snapback]

The attached spread sheet has some performance data on OpenGOOP, niGOOP (GOOP) and dqGOOP. I created dqGOOP for performance, but unfortunately it requires LabVIEW 7.0 or later (it sounds like you're using 6...). Mark Balla started a discussion on dqGOOP here:

http://forums.lavausergroup.org/index.php?...=1392#entry4739

The first post has a zip file GOOPTest.zip that has three test classes (LV 7.0) and a performance test VI for each (in the Testing folder). [Two weeks of discussion on dqGOOP was recently lost due to an attack on the LAVA discussion forums]

OpenGOOP doesn't support named objects, but since it is open you could add that functionality. dqGOOP uses LabVIEW native queues so it supports named objects, with the added advantage that unique references are created when you obtain a reference by name.

I have not been able to test GOOP 2.0 performance or the new GOOP developer posted by Kurt Friday at:

http://forums.lavausergroup.org/index.php?...=1355#entry4509

Brian

[brian175]

The attached spread sheet...

4754[/snapback]

This time I'll try a zip file

Download File:post-987-1116208154.zip

[Mark Balla]

There was another discussion about the OpenG goop here

http://forums.lavausergroup.org/index.php?showtopic=1109&hl=

It has some tips on avoiding issues that other programmers have run into.

[MagicWand]

I couldn't edit my first post, so I add yet another question here:

I looked at the diagram of <Class> Open Object Reference.vi.

I'm no expert, so why is Flatten to String and then Flatten from String used in the diagram?

Wouldn't a Type Cast do the same job ???????

[Mark Balla]

I couldn't edit my first post, so I add yet another question here:

I looked at the diagram of <Class> Open Object Reference.vi.

I'm no expert, so why is Flatten to String and then Flatten from String used in the diagram?

Wouldn't a Type Cast do the same job ???????

4761[/snapback]

Yes. in dqgoop it is done this way.

Also "OpenGOOP Data Core.vi" does the opposite conversion.

If you want you can make changes in the "_OpenGOOP_classtpt" folder.

The wizard uses these vis to create classes.

[brian175]

Yes. in dqgoop it is done this way.

Also "OpenGOOP Data Core.vi" does the opposite conversion.

If you want you can make changes in the "_OpenGOOP_classtpt" folder.

The wizard uses these vis to create classes.

4768[/snapback]

Yes dqGOOP uses the type cast, but LabVIEW doesn't allow a (reentrant?) VI refnum to be the input type to the type cast function. I remember reading that the flatten => unflatten was the "trick" needed to enable converting the Object refnun to the VI data store refnum.