LabVIEW
change class private data to protected
Nope. The LabVIEW class data cluster is always private. You need to create accessor VIs that you can also decide if they are private, protected, community, or public in order to access them from anything else than the own class. You can create them as normal methods with arbitrary connector pane (except of course the class connectors and the error clusters) or special properties which need to follow a strict connector pane layout but can then be accessed by a LabVIEW property node too instead of placing the property VI in your diagram.
And make sure those accessor VIs are protected!
You don't want the entire world to start using them, just the child classes.
Search LabVIEW like a graph!
@Pierre_F wrote:
I don't like this way of programming a lot because adding accessors that have normal VI shape make it very ambiguous. furthermore it add items in the project hierarchy, and make everithing less readable and heavyier.
You shouldn't like it. If you need a ton of private accessors, you might be doing it wrong. Public accessors are even worse. There are acceptions (classes that manage public data), but normally, a class should not expose it's data, as that will often expose it's implementation. The general advice is to refactor so the child calls the parent instead of querying data from the parent, that basically is asking the parent to expose it's implementation.
@Pierre_F wrote:
In a general I find the labview classes management not very optimized.
You mean how LV manages classes (efficiency) or how it makes us manage classes? I agree on the latter.
@Pierre_F wrote:
I think to would be better to reduce, for example, amount of VI by agglomerating class VIs inside a common diagram and identify functions/ and access rights separately inside this diagram.
You lost me there... I like the methods in the project so I can drag\drop them. Don't want them hidden even more clicks away.
@Pierre_F wrote:
I wander how it is managed in NXG.
Pretty sure the private scope of parent data will be the same. I'd be surprised if there isn't a documented reason for this. Efficiency or technical difficulty if I had to guess.
There won't be a diagram agglomerating class VIs either.
The NXG IDE is a much better environment for customization. Both NI as users\partner will be able to make changes a lot easier. So I think the class management will evolve a lot faster.
You're over thinking it. Right click on the class and select New... then "For Data Member Access". It'll open a popup and you can select which elements you want to make accessors for.
Check the box for Make Available in Property Node, then click OK and it'll auto-create the accessors for you. You can also access these accessors via Property Nodes, which makes things much more readable, and you never need to use the actual VI's themselves. You can also keep all of your accessors in a Virtual Folder in the project and never have to look at them.
The Property Node will call the Accessor VI, which is used to read/write the data, but wiebe@CARYA is right- if you have tons of accessors, you may want to rethink how your code handles things. It's not a hard and fast rule, but it should be a goal to minimize the number of accessors you use that cross class boundaries, as each class should try to "take care of itself".
@BertMcMahan wrote:
You can also access these accessors via Property Nodes, which makes things much more readable, and you never need to use the actual VI's themselves.
I really don't like them. I don't see how they are more readable, they seem 'alien' to me. But we don't have to agree on every nitpicky style detail.
That's reasonable- I just hate having to edit every single accessor VI's icon, as otherwise it's just a blank square. A property node gives you a single textual piece of information saying what it's doing, and IMHO it organizes my wires better as I can have multiple accessors in one property node grouped by function.
I'm curious, how do you make your accessor VI's quickly readable? Or do you have another method you'd prefer to see that may or may not be implemented? I typically like property nodes but I'm always looking out for good ways to lay out diagrams.
(Side note: I typically like property nodes for when I need two or three accessors at once, like if I'm doing a class Initialize function and need to set a handful of properties. If I'm just using one accessor, a standalone VI is usually much cleaner).
(Side side note: when I said "You're over thinking it" I was talking to the OP, not you wiebe :))
@BertMcMahan wrote:
(Side side note: when I said "You're over thinking it" I was talking to the OP, not you wiebe :))
It crossed my mind, but figured that it wasn't directed at me (although probably true anyway ).
@BertMcMahan wrote:
That's reasonable- I just hate having to edit every single accessor VI's icon, as otherwise it's just a blank square. A property node gives you a single textual piece of information saying what it's doing, and IMHO it organizes my wires better as I can have multiple accessors in one property node grouped by function.
Just mentioned that because when looking for solutions or improvements it's very hard to please everyone. One might expect that everybody likes to do thinks with method A, so A get's improved, while people using B can't do B any more because A got improved. Not good.
@BertMcMahan wrote:
I'm curious, how do you make your accessor VI's quickly readable? Or do you have another method you'd prefer to see that may or may not be implemented? I typically like property nodes but I'm always looking out for good ways to lay out diagrams.
I guess I don't have a quick way to make accessor VIs. Usually make one from scratch, and then save as... for each new one. Doing it 20 times a day streamlined the process. Frankly, I do it faster myself then to use the 'wizard' and tweak the output (read\write is terrible, have to change it to get\set).
I never got to use property nodes because a) it's extra steps (wizard+tweaks takes longer) and b) I don't like to use them. c) often the get an additional input anyway, maybe a 'skip' Boolean or something like that.
If there was a way to select what data is supposed to be public\protected, and those data members would automatically become available as properties, I'd probably use those properties.
The now private data members should definitely never ever be made protected by default or all together. It would need to be on an individual bases, and explicitly done by a user. But like I said before, this has been suggested before (probably in the idea exchange)...
