GOOP object creation

[CuriousSwede]

Dear group,

I´m sure there is a good reason why part of the code for creating a GOOP object looks like this,

but why isn´t it implemented a little bit simpler and clearer like this instead?

[Jay14159265]

Many people dont like to view the constant as an icon because it takes up so much space. Of course the ones you are looking at only have one or two items, but some have many more and it takes up too much screen realistate. 

Instead of always having icons to show all container elements on screen, try using ctrl+H and hover over objects to see what they are made of. 

[CuriousSwede]

Perhaps you misunderstood my last diagram. It’s not the terminals shown as icons, it’s them being replaced by constants.

[Jay14159265]

---

@CuriousSwede wrote:

Perhaps you misunderstood my last diagram. It’s not the terminals shown as icons, it’s them being replaced by constants.

---

Ah I see, well if it is implemented with a terminal than it is inviting the developer to pass a value to the VI, or use the default if unwired value. For LVOOP, the front panels of childs must match the parent so even if you don't use a front panel terminal it still has to be there. Maybe that is the issue. 

[CuriousSwede]

The two FP controls, DVRRef(Hidden) and Data, are not connected to any icon terminal. So it seems as if it´s fine to replace them both with a DVR constant and Data type definition directly on the BD. However there is probably a deeper reason for the way it´s originally done. Perhaps it has something to do with the scripting used by GOOP to create the VI, but I know close to nothing about scripting, so I don´t know.

[Jay14159265]

---

@CuriousSwede wrote:

The two FP controls, DVRRef(Hidden) and Data, are not connected to any icon terminal. So it seems as if it´s fine to replace them both with a DVR constant and Data type definition directly on the BD. However there is probably a deeper reason for the way it´s originally done. Perhaps it has something to do with the scripting used by GOOP to create the VI, but I know close to nothing about scripting, so I don´t know.

---

You know I have used LVOOPS (LabVIEW Object Oriented Programming System) for years and thought that was a great acronym but somehow LVGOOP is so much better. Its like what happens when you overcook spaghetti : ) 

Oh yea and I have never used GOOP so I don't know what the built in scripting does but if you delete the FP object and the code compiles, then its ok to delete the FP object. 

[raphschru · Accepted solution]

As CuriousSwede noticed, these controls are not assigned to the connector pane. Also, "DVRRef(Hidden)" is only used for its type, not for its value. I think the reason why these are controls and not constants is indeed to simplify the scripting done when GOOP creates the class.

If you check folder "<LabVIEW>\resource\Framework\Providers\Open_GDS\ClassProviders\Common\ScriptingFunctions", there are scripting VIs to create a GOOP class (notice I have "Open_GDS" in the path, meaning I use the open source version of the toolkit, not the NI one).

The VI "Scripting_ReplaceVisAndControls.vi" is in charge of replacing old subVIs and type-defined controls with new ones. Having code that also replaces type-defined constants would have been possible, but is redundant with the code for replacing controls, so I guess a choice was made to turn these specific constants into controls…

Regards,

Raphaël.

[CuriousSwede]

Thanks for your answer Raphaël, and thanks for the link to the open source version of the toolkit. In the help file there, GOOP Development Suite, I found some really interesting information.