Public .ctl with private members

[Ton Plomp]

Consider the following, you have a library that has private controls. For use inside other VI's you construct a typedef .ctl that contains some off these controls and make the typedef .ctl public.

Now if you use this typedef inside another VI/Ctl the VI/CTL will be broken since it refers directly to the private members :thumbdown: . I was hoping that the public .ctl refered to the private members allowing a good use to these items....

Does anyone have an idea why? and how to bypass this.

The error:

This VI cannot access the referenced item because of library access scope. Private library items can only be accessed from inside the same library or libraries contained in that library. Protected library items can only be created inside LabVIEW classes and can only be accessed from inside the same LabVIEW class or LabVIEW classes inheriting from that class.

Ton

[TG]

QUOTE(tcplomp @ Feb 15 2007, 03:20 AM)

Consider the following, you have a library that has private controls. For use inside other VI's you construct a typedef .ctl that contains some off these controls and make the typedef .ctl public.

Now if you use this typedef inside another VI/Ctl the VI/CTL will be broken since it refers directly to the private members :thumbdown: . I was hoping that the public .ctl refered to the private members allowing a good use to these items....

Does anyone have an idea why? and how to bypass this.

The error:

This VI cannot access the referenced item because of library access scope. Private library items can only be accessed from inside the same library or libraries contained in that library. Protected library items can only be created inside LabVIEW classes and can only be accessed from inside the same LabVIEW class or LabVIEW classes inheriting from that class.

Ton

I hope you get a good answer to this one Ton. I have encountered this too. The encapsulation paradgim in LabVIEW

whereby all private data is accessible only by members of the class is a good idea, but how does one deal with public type definitions which may (by design) include some of these types in them as the structures develop in complexity?

It can get rather complicated.

I have actually changed the scope of some of my private elements to public to get around it (rather dirty I agree)

Im sure there is a better way, but being in a little over my head I have not the time to find the correct solution

(if there even is one.)

[Aristos Queue]

QUOTE(John Rouse @ Feb 15 2007, 12:27 PM)

I have actually changed the scope of some of my private elements to public to get around it (rather dirty I agree)

Why is it dirty? You want them to be public then make them public. If you don't want them to be public, why are you putting them on the FP of VIs outside of your library? If you want a datatype that keeps its insides private, that's what LabVIEW classes are for. But if you use a typedef, you darn well better have the rights to use *all* of that typedef because all of it is hanging out in the open.

File the bug report if you want, but it'll get closed "Not A Bug." :-)

[TG]

QUOTE(Aristos Queue @ Feb 16 2007, 10:22 AM)

Why is it dirty? You want them to be public then make them public. If you don't want them to be public, why are you putting them on the FP of VIs outside of your library? If you want a datatype that keeps its insides private, that's what LabVIEW classes are for. But if you use a typedef, you darn well better have the rights to use *all* of that typedef because all of it is hanging out in the open.

File the bug report if you want, but it'll get closed "Not A Bug." :-)

Thanks Aristos

Your answer is what I was looking for even if I did not realize it right away.

It not good practice to use a control outside its protection scope anyway.

I just hate realizing that my original design won't hold up as the APP complexity grows.

I need that type definition outside the class so, I'll just make it public and get on with it.

JR

[Ton Plomp]

QUOTE(Aristos Queue @ Feb 16 2007, 04:22 PM)

File the bug report if you want, but it'll get closed "Not A Bug." :-)

Not reported because I realize it is how it is meant to be

It is more a convenience issue, we have some GPS lvlib's, where the main datatype is a typedef with 10 or so elements including 4 enum's.

So for a program where I want to build data for the lvlib or display data from the lvlib I set my data-cluster to public. The reason for the public datatype is that it is just a subset of all data we've got (that is about 40 elements, mainly debug). But in order to use the public datatype, all it's enums have to be public also, not really an issue but an inconvience, the structure of the public part of the lvlib grows unnesecarily in size...

So I've decided to just declare all my controls private, making it look more complicated than it is...

Ton

Sorry it turned kinda into a rant post, not meant to be

[Tomi Maila]

QUOTE(tcplomp @ Feb 17 2007, 03:02 PM)

Not reported because I realize it is how it is meant to be

It is more a convenience issue...

Ton, I suggest you post NI a change request. Don't request the functionality to change because it will not happen. Request change in the user interface of the LabVIEW development environment. Request that LabVIEW allows user to make all referenced private typedefs public for a public typedef. The same should apply for public VIs, the connector pane of which refers to private typedefs. There simply could be a new option "apply same option to all referenced items", where item means typedefs and classes and referenced means what I explained above.

Tomi

[Mellroth]

QUOTE(Tomi Maila @ Feb 17 2007, 07:41 PM)

Ton, I suggest you post NI a change request. Don't request the functionality to change because it will not happen. Request change in the user interface of the LabVIEW development environment. Request that LabVIEW allows user to make all referenced private typedefs public for a public typedef. The same should apply for public VIs, the connector pane of which refers to private typedefs. There simply could be a new option "apply same option to all referenced items", where item means typedefs and classes and referenced means what I explained above.

Tomi

I don't really work with LVOOP yet, but I really think private items should stay private.

If I define something to be private, its because I would like to make sure that a end-user doesn't use this item (shouldn't even be aware of that the private items exist). If the end-user can not access the internal/private parts of the system, then they can be changed without affecting the end-user at all.

Allowing the user to break this "rule", would probably lead to situations where the higher levels in your program needs to be recompiled (or be broken), even though it is only an internal part of a subclass that has changed.

/J

[Ton Plomp]

QUOTE(JFM @ Feb 18 2007, 10:52 AM)

I don't really work with LVOOP yet, but I really think private items should stay private.

To be clear this goes for lvlib's (at least my case).

Ton