GOOP Development Suite v4.5 is released

[burd]

It's nice that you like it.

Here is another example form the same book.

Design.png

Re: Design Patterns

Hi Mikael,

 

When I run the remoteloader.vi in the CommandPattern project I get the error 1100:

 

Obtain Queue in RemoteControl.lvclass:GuiRepository.vi->RemoteControl.lvclass:ControlGuiWindow. vi->RemoteLoader.vi

 

I am wondering if this error has anything to do with the labview version I am using (2013).

 

thanks

 

Helcio

[MikaelH]

Re: Design Patterns

Hi Mikael,

 

When I run the remoteloader.vi in the CommandPattern project I get the error 1100:

 

Obtain Queue in RemoteControl.lvclass:GuiRepository.vi->RemoteControl.lvclass:ControlGuiWindow. vi->RemoteLoader.vi

 

I am wondering if this error has anything to do with the labview version I am using (2013).

 

thanks

 

Helcio

Sorry I just saw that I use my own dialog VI, in the Door,Fan and Light classes.

Replace the VI: LcDialog_AutoSizeDialog.vi, with a single One utton Dialog.

The VIs you need to update are:

GarageDoor_classOpen.vi  Close.vi

Light_classOn.vi Off.vi

CeilingFan_classSetSpeed.vi

[burd]

Ok, I will check that!

 

thanks

Edited June 12, 2014 by burd

[Ad Dekkers]

I'm working on it, you can try this solution, it looks likes it works in 2012 at least.

But I'm not sure if it should work, we better ask NI.

Make sure you convert the number string to U32, not I32 that is the default

RefCheckGoop4.png

Cheers,

Mike

Or like this?

 

 

[MikaelH]

Absolutely, but if you want to make it a Generic VI, it’s a bit harder.

But if you don’t mind adding a VI like that in all your classes, that would be the easiest way.

[Ad Dekkers]

Perhaps the tool should create this vi on class birth?

Something for NI ?

[MikaelH]

You can easily do this yourself by modifying the class templates located in this folder:

LabVIEW 20XX\resource\Framework\Providers\XXXXXXXXX\ClassProviders\Provider_EndevoGOOP400\Templates

 

In the latest release on OpenGDS, I have fixed this in the utility VI:

LabVIEW 20XX\vi.lib\addons\GOOPUtility\GOOPUtil_IsValidReference.vi

[Rolf Kalbermatter]

An �empty� object in LabVIEW is just the default constant of that wire type.  So you can just ask if your �Dough� is not equal to the default �Dough� constant.

 

 

That is only half the truth. For an unitialized object reference you are right but for an object reference that has been created and then destroyed the actual refnum value is not null but still not valid anymore!

 

There should be something akin to "Not a Number/Path/Refnum" for object wires. In fact I was at first assuming that LabVIEW objects are inherently also refnums but that seems not really the case. And extending "Not a Number/Path/Refnum" to "Not a Number/Path/Refnum/Object" would seem logical but the resulting long name sounds like a bad idea.

[drjdpowell]

That is only half the truth. For an unitialized object reference you are right but for an object reference that has been created and then destroyed the actual refnum value is not null but still not valid anymore!

I’m not familiar with by-ref GOOP, but I imagine GOOP objects wrap a reference of some kind (DVR?).  So you are right, one needs to consider stale refnums.  However, there’s a difference between something that might be called “null†versus something that is “invalid".  An “abstract†parent object might indicate a no-op, while a destroyed object might indicate an error condition.  I forget what the OP was requesting.

[Rolf Kalbermatter]

I’m not familiar with by-ref GOOP, but I imagine GOOP objects wrap a reference of some kind (DVR?).  So you are right, one needs to consider stale refnums.  However, there’s a difference between something that might be called “null†versus something that is “invalid".  An “abstract†parent object might indicate a no-op, while a destroyed object might indicate an error condition.  I forget what the OP was requesting.

 

I didn't mean to indicate that an object reference is a by-ref implementation. But I have a hunch that an object wire on the LabVIEW diagram is similar to other refnums. The use of a refnum doesn't have to mean that the object is by-ref. It's only a matter of how LabVIEW implements the rules to access the underlaying object that defines by-ref or by-value implementation.

 

As such implementation of a "Not an Object" primitive would be not that difficult. But maybe they didn't do that so far as they might want to solve a few more issues with Not a Number/Path/Refnum to allow some distinction between the canonical invalid underlying object type for Refnums and Objects and the once allocated but later destroyed object type.

[drjdpowell]

As I understand it, LVOOP objects are extensions of by-val clusters, not refnums.  There is no create nor destroy action and no meaning to “Not and Objectâ€; there is always a valid object.  If the objects class contains a refnum of something as an element (a Queue, say), then that will be uncreated by default, and you can write a class method that tests that refnum, but that is not the same as “Not an Objectâ€.

[Rolf Kalbermatter]

You might be right there. I guess I was assuming that there must be a difference between an initialized object and one that hasn't been initialize yet since there is this Get LV Class Default Value.vi. But I guess any class has as soon as it gets placed on a diagram a cluster and the To More Specific Class simply compares that the underlaying object has a matching method AND cluster definition and in that case copies the class data into the existing cluster. Makes sense from a by val architectural point of view. As such there is indeed no Not an Object but only a Default Data state, which is the equivalent of the Class data cluster having all default data elements.

[burd]

I'm working on it, you can try this solution, it looks likes it works in 2012 at least.

But I'm not sure if it should work, we better ask NI.

Make sure you convert the number string to U32, not I32 that is the default

RefCheckGoop4.png

Cheers,

Mike

 

 

Hello Mikael,

 

I wonder if the VIs in the GOOP Utility pallet work for GOOP4 classes in the version 1.0.37[37] which is the version I am currently using. I seems that it does not because I get errors when using them. Did you fix them so that they can work with GOOP 4 classes?

 

thanks

 

Helcio

Edited March 27, 2015 by burd

[MikaelH]

Which one is giving you a problem?

The "IsValidReference" has been changed to support GOOP4, but some of the other should work.

The green once should probably work, but not the red ones.

[burd]

Which one is giving you a problem?

The "IsValidReference" has been changed to support GOOP4, but some of the other should work.

The green once should probably work, but not the red ones.

GoopUtil.png

Hi Michael,

 

The ones you marked in red were the problem. Good to know that most of the utilities work for Goop4 classes!

 

Thank You!

 

Helcio