Jump to content

GOOP Development Suite v4.5 is released


Recommended Posts

It's nice that you like it.

Here is another example form the same book.

attachicon.gifDesign.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

Link to comment

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

Link to comment
  • 1 month later...

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

Link to comment

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.

Link to comment

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.

Link to comment

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.

Link to comment

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â€.

Link to comment

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.

Link to comment
  • 7 months later...

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

attachicon.gifRefCheckGoop4.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 by burd
Link to comment

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.

attachicon.gifGoopUtil.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

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.