New GOOP tool from Endevo

[Jan Klasson]

Hi all,

I am happy to inform you that Endevo has released a new generation of GOOP tool for LV 8.2.1 - The GOOP Development Suite v1.0!

It supports three (!) different class models:

- native LabVIEW by-value classes

- Endevo GOOP 3 - adding the by-reference model to lvclass

- OpenG class templates (developed by Tomi Maila, read his post) - a LV Queue based by-reference model for lvclass

Fully integrated in the LabVIEW project environment.

Icon editors.

User definied class and method templates for all three class models.

Visit http://www.endevo.se/content/view/109/107/lang,en/ an read more.

Free trials and a free Community Edition.

Hopefully the only GOOP tool you will ever need:-)

Jan Klasson and Mike Holmström

Endevo

[Tomi Maila]

Here is a link to the OpenG Class Templates thread.

[Kurt Friday]

Congratulations Mike, Tomi and Jim on some truly beautiful work

[Tomi Maila]

I'd like thank Endevo and especially Mikael Holmström and Jan Klasson for supportting open source templates. Without support from Endevo there would not be open source class templates as there would not be an easy way to use these templates.

Tomi

[Jan Klasson]

Hi all,

I am happy to inform you that Endevo has released a new generation of GOOP tool for LabVIEW 8.2.1 - The GOOP Development Suite v1.0!

It supports three (!) different class models:

- native LabVIEW by-value classes

- Endevo GOOP 3 - adding the by-reference model to lvclass

- OpenG class templates (developed by Tomi Maila, read his post) - a LabVIEW Queue based by-reference model for lvclass

Fully integrated in the LabVIEW project environment.

Icon editors.

User definied class and method templates for all three class models.

Visit http://www.endevo.se/content/view/109/107/lang,en/ an read more.

Free trials and a free Community Edition.

Hopefully the only GOOP tool you will ever need:-)

Jan Klasson and Mike Holmström

Endevo

[MikaelH]

Hi everyone

I just attached a small LabVOOP application created with the GDS tool.

http://forums.lavag.org/index.php?act=attach&type=post&id=6099

I used this application to evealuate if LabVOOP supports recursive calls.

But unfortunattly it doesn't :headbang:

Limitations:

First: You can't set a dynamic dispatch method to be reentrant.

Second: You can't call a dynamic dispatch VI using the "Call By Reference Node"

Cheers,

Mikael

[Jim Kring]

QUOTE(MikaelH @ Jun 14 2007, 03:13 PM)

But unfortunattly it doesn't :headbang:

Limitations:

First: You can't set a dynamic dispatch method to be reentrant.

Second: You can't call a dynamic dispatch VI using the "Call By Reference Node"

Hi Mikael,

Thanks for the example. I've been using the GDS all day and really like it

These limitations that you mention are really too bad. I've heard that the reason A-->B-->A recursion isn't allowed is simply to avoid infinite recursions (protect us from ourselves, which is really annoying). In your example, you could still do the recursion that you want, but you would need to inspect each SubNode's type and do an old-fashion recursion (VI Server or Loop-Stack) if it is a Container and only call the Node::Draw function if the Node is not a container -- that's a lot of work! Here's an example of how to do it (I've modified your project to get the recursion working):

http://forums.lavag.org/index.php?act=attach&type=post&id=6100

http://forums.lavag.org/index.php?act=attach&type=post&id=6101

Thanks,

-Jim

[Aristos Queue]

QUOTE(Jim Kring @ Jun 14 2007, 08:59 PM)

I've heard that the reason A-->B-->A recursion isn't allowed is simply to avoid infinite recursions (protect us from ourselves, which is really annoying).

If we were protecting you from infinite recursion at runtime, you'd be correct that we were just protecting you from yourselves and being over-parental. No, the problem was infinite allocation at compile time. Just the act of dropping a node would create infinite allocations. The definition of reentrancy -- every node has its own instance to execute. If every node has one, then it's like staring into a mirror just to initialize the VIs.

[Jim Kring]

QUOTE(Aristos Queue @ Jun 15 2007, 03:27 PM)

If we were protecting you from infinite recursion at runtime, you'd be correct that we were just protecting you from yourselves and being over-parental. No, the problem was infinite allocation at compile time. Just the act of dropping a node would create infinite allocations. The definition of reentrancy -- every node has its own instance to execute. If every node has one, then it's like staring into a mirror just to initialize the VIs.

Is there a reason why A-->B-->A recursion can't work for Dynamic Methods that are reentrant? Is this on the roadmap?

[Ton Plomp]

I have an issue with the Endevo software, I get a lot of times the License Agreement and have to do the whole activation over again, does someone else see that?

Ton

[Tomi Maila]

Hi Ton,

Try to do the activation via Tools -> GOOP -> Product information. That may work.

Tomi

[TG]

Thanks Jan

Q:

Can this tool be activated on a non networked machine?

I have two rigs that are forbidden to be connected and have 8.2.1 instaslled on them.

I wanted to ask here bafore I go ahead and try it anyway.

Regards

John

Thanks Jan

Q:

Can this tool be activated on a non networked machine?

I have two rigs that are forbidden to be connected and have 8.2.1 instaslled on them.

I wanted to ask here bafore I go ahead and try it anyway.

Regards

John

[Ton Plomp]

QUOTE(Tomi Maila @ Jun 21 2007, 11:51 AM)

Hi Ton,

Try to do the activation via Tools -> GOOP -> Product information. That may work.

Tomi

I didn't have that option, but when I restarted LabVIEW a 'internal error' dialog came up and I didn't have to activate anymore.

Ton

[TG]

QUOTE(Tomi Maila @ Jun 11 2007, 06:15 PM)

Here is a link to the http://forums.lavag.org/index.php?showtopic=8419&pid=31382' target="_blank">OpenG Class Templates thread.

Thanks for all the hard work on the OpenG Class templates. I am really looking forward to seeing the templates in action on my rig.

and also to learn. I want to see the active object template the most (it fits into what I am looking to do)

I am having some difficulty installing correctl them however.

I installed the class folders files into the ...Resource\framework\providers\Endevo\ClassProviders\Provider_EndevoGOOP300\Templates.. folder and manage to get the Endevo tool to register them but when I try to create a class in the project I get a lot of file searching then

some errors and sometimes crashes.

Here are the names of the files I DLed from OPENG

oglib_openg_object-1.0beta4-1.zip

ogrsc_val_obj_tmpl-1.0beta2-1.zip

ogrsc_ref_obj_tmpl-1.0beta1-1.zip

ogrsc_pure_abstract_ref_class_tmpl-1.0beta1-1.zip

ogrsc_active_obj_tmpl-1.0beta1-1.zip

Q is where should I put these class folders so that Endevo tool sees them and loads then proper?

[Jim Kring]

QUOTE(John Rouse @ Jun 26 2007, 12:15 PM)

Thanks for all the hard work on the OpenG Class templates. I am really looking forward to seeing the templates in action on my rig.

and also to learn. I want to see the active object template the most (it fits into what I am looking to do)

I am having some difficulty installing correctl them however.

I installed the class folders files into the ...Resource\framework\providers\Endevo\ClassProviders\Provider_EndevoGOOP300\Templates.. folder and manage to get the Endevo tool to register them but when I try to create a class in the project I get a lot of file searching then

some errors and sometimes crashes.

Here are the names of the files I DLed from OPENG

oglib_openg_object-1.0beta4-1.zip

ogrsc_val_obj_tmpl-1.0beta2-1.zip

ogrsc_ref_obj_tmpl-1.0beta1-1.zip

ogrsc_pure_abstract_ref_class_tmpl-1.0beta1-1.zip

ogrsc_active_obj_tmpl-1.0beta1-1.zip

Q is where should I put these class folders so that Endevo tool sees them and loads then proper?

Do not manually install the package files. Download them as OGP files (how did they get renamed as ZIP) and install them using VIPM, per http://wiki.openg.org/OpenG_Class_Templates_for_LabVIEW_Object-Oriented_Programming#Obtaining_and_Installing_Templates' target="_blank">the instructions.

Thanks,

-Jim

[TG]

QUOTE(Jim Kring @ Jun 26 2007, 07:33 PM)

Do not manually install the package files. Download them as OGP files (how did they get renamed as ZIP) and install them using VIPM, per http://wiki.openg.org/OpenG_Class_Templates_for_LabVIEW_Object-Oriented_Programming#Obtaining_and_Installing_Templates' target="_blank">the instructions.

Thanks,

-Jim

Sorry

They are zip files on my machine. If they were OGP files somehow my OP system (or IE)

inperpret them as zip files.

Stranger things have happened. Hehe WinXP.

Anyway that was the reason why nothing was making any sense

I'll try to see if its on my end.

Thank You

JR

[EDIT]

Apparently WinXP takes the liberty of interpreting the file type not the extension.

Id be suprised if my rig was the only one doing this.

I have installed the templates now.

Q is how do I get Endevo tool to 'see' them What directory are they in?

Thank You

JR

I found it

C:\Program Files\National Instruments\LabVIEW 8.2\resource\OpenG\openg_object\class_templatess

[Ton Plomp]

QUOTE(tcplomp @ Jun 21 2007, 11:27 AM)

I have an issue with the Endevo software, I get a lot of times the License Agreement and have to do the whole activation over again, does someone else see that?

Ton

And there's a solution!

Endevo places a license file in the LabVIEW temp folder, which by default is the same as the Windows Temp folder (run %temp% to see yours).

Mine is flushed on every boot.

By moving the LabVIEW temp folder from the settings myh license file survives a reboot.

Ton

[Dirk J.]

Hmmm....

Thanks for figuring that out, that's a time-saver!!

QUOTE(tcplomp @ Jul 5 2007, 05:32 PM)

By moving the LabVIEW temp folder from the settings myh license file survives a reboot.

Ton

[Aristos Queue]

QUOTE(MikaelH @ Jun 14 2007, 05:13 PM)

Limitations:

First: You can't set a dynamic dispatch method to be reentrant.

Second: You can't call a dynamic dispatch VI using the "Call By Reference Node"

In most situations, you can get around the Call By Ref limitation by creating a static VI that just calls the dynamic subVI, and then using Call By Ref to invoke the static VI. Not as nice as being able to do the invocation directly, but it does work.

As for the lack of reentrancy on the dynamic dispatch VIs, let me just say that I think that's a serious limitation of the language and some NI software engineer ought to do something about that in a future LV version.

By the way, to Jan, Mikael, Tomi, and Jim,

I was knee-deep in work for a future LV version when the toolkit released, so I never got a chance to say this formally and publically: Congratulations and thank you. Your tool is a valuable addition to the OO resources of LabVIEW.

-- Stephen Mercer

-= LabVOOP Lead Engineer =-