A Class's Private Data and A Tab Control

[Yamaeda]

I cant really see where it'd be a good solution, as a tab control basically is just a visibility macro for other controls, it's not really data in itself and you'll hide information about the class.

/Y

[tst]

---

@Yamaeda wrote:

...it's not really data in itself and you'll hide information about the class.

---

It's not supposed to be data. It's an organizational tool for the person creating and editing the cluster (again, this is isn't specifically about classes).

It will also hide about as much data as is hidden now when your cluster is larger than your FP and you have to scroll down to see all of it, except that with this it could be more accessible.

Like I said, see the idea Darin linked to earlier. Any arguments for or against this should really go in there - http://forums.ni.com/t5/LabVIEW-Idea-Exchange/Allow-clusters-to-have-quot-pages-quot/idi-p/1481862

[User002]

---

@tst wrote:

---

@Yamaeda wrote:

...it's not really data in itself and you'll hide information about the class.

---

It's not supposed to be data. It's an organizational tool for the person creating and editing the cluster (again, this is isn't specifically about classes).

(...)

---

Ah, ok, I am enlightened. Kudos for the idea to have tabs in the class, even though the tab itself isn't a data type inside the class/cluster.

Or at least make class/cluster controls scrollable.

On a side note, if the class/clusters become too unwidely, it is perhaps better to redesign, than to start organizing the cluster/class with for example UI elements, such as tabs, and ending up with a monstrosity?

Br,

/Roger

[Norbert_B]

---

@tst wrote:

But what do you do if the class DOES need a lot of specific data which can't be split up? In the idea Darin linked to, I gave the example of the VI server hierarchy. If you take the Control class as an example, it has a couple of dozen  properties, and that's just the ones which are visible through VI server. All that data needs to be saved somewhere.

---

Granted, there are classes where the number of 'new' properties exceed maybe 20. But first of all, this should not be "the standard". And second note: Even "control" inherits about 1/3 of all its total properties from ancestor classes, like "GObject".

I didn't want to look like "if you have too much properties, you are a fail in software development and should discard anything". What i was trying to say is: "If you see your classes normaly to get many properties as such that you REQUIRE visual indication of different 'types of properties', you might want to reconsider your approach and gather each group of properties into subclasses you use within your main class".

I hope this clears things up a bit,

Norbert

[tst]

---

@Norbert_B wrote:

But first of all, this should not be "the standard".

I didn't say anything about "standard". There are some classes (and other clusters) where this could be useful. Someone brought up XControl state clusters as another good example.

And second note: Even "control" inherits about 1/3 of all its total properties from ancestor classes, like "GObject".

I was talking specifically about the ones from the Control class. Counting now, I see 56 properties (see a full list below), and that doesn't include those which are owned by the Control class, but which actually come from different classes, like the Label and Captions properties, nor does it include additional data which is not exposed by VI server.

What i was trying to say is: "If you see your classes normaly to get many properties as such that you REQUIRE visual indication of different 'types of properties', you might want to reconsider your approach and gather each group of properties into subclasses you use within your main class".

I don't think that makes sense either architecturally or from a usability point of view. The class simply represents an object which has a lot of data associated with it, just like the Control class. It's not sub-objects owned by the cluster (aggregation). It's simply primitive data which belongs to the object. Also, that data needs to be easy to access and aggregation makes it harder to write the accessor code.

VI server properties from the Control class:

01. Auto-Update From Typedef
02. Bit Accurate Data Size
03. Blinking
04. C Type
05. Caption
06. Control Reference Nodes[]
07. Data Binding:Binding Type
08. Data Binding:Blink On Alarm
09. Data Binding:LED Visible
10. Data Binding:Mode
11. Data Binding: Path
12. Data Binding: Persist ID
13. Data Binding: Status
14. DataSocket:Enabled
15. DataSocket:LED Visible
16. DataSocket:Mode
17. DataSocket: Status
18. DataSocket:URL
19. Default Value
20. Description
21. Disabled
22. Focus Key Binding
23. Genericity
24. Grow Info
25. Grow Info:Can Grow Horizontally
26. Grow Info:Can Grow Vertically
27. Grow Info:Max Horizontally
28. Grow Info:Max Vertically
29. Grow Info:Min Horizontally
30. Grow Info:Min Vertically
31. Has Caption
32. Indicator
33. Invoke Nodes[]
34. Is On Connector Pane
35. Is Stub?
36. Is Typedef?
37. Key Focus
38. Label
39. Latch Value
40. Local Variables[]
41. Property Nodes[]
42. Skip When Tabbing
43. Style ID
44. Synchronous Display
45. Terminal
46. Tip Strip
47. Typedef: Path
48. Typedef:VI
49. Value
50. Value (Signaling)
51. Visible
52. Wizard Data
53. XControl:Container Bounds
54. XControl:Container Bounds:Height
55. XControl:Container Bounds:Width
56. XControl:Is XControl?

[Norbert_B]

---

@tst wrote:

[..]

I was talking specifically about the ones from the Control class. Counting now, I see 56 properties (see a full list below), and that doesn't include those which are owned by the Control class, but which actually come from different classes, like the Label and Captions properties, nor does it include additional data which is not exposed by VI server.

[..]

07. Data Binding:Binding Type
08. Data Binding:Blink On Alarm
09. Data Binding:LED Visible
10. Data Binding:Mode
11. Data Binding: Path
12. Data Binding: Persist ID
13. Data Binding: Status
[..] 

---

Hm, ok, that explains a lot. I have 37 properties "top-level" within "Control" as 'class specific properties', so not inherited. I have some additional stuff enabled, so it is more than you are seeing.

As marked in my quote, you have properties "collected" in a top-level item. I don't know how VI Server is architectured here, but if i would design such classes, i would create a class for "Data Binding". So my "Control" class would contain an object of "Data Binding", which would build up aggregation, true.

For the accessability: There is always some factionalism about how to design classes and their relationships. There are developers who demonize direct access to class data by properties; they insist on methods. Others provide general access to class data by properties, only building methods for encapsulation of complex computations (like stored procedures in databases). VI Server is somewhere inbetween.

So why would it be "less accessable" if i would provide an accessor method for the aggregated class data? Well, true, you had to use an additional node (if not working with .NET and its 'dot-notation'). But is it less accessable/less readable/less maintainable? I am not sure.....

But i think we are drifting into very basic OOD discussions not necessarily related to the question/remark of the OP. And as stated before, i understand the wish to have tab controls available in class data clusters, but i for myself try to avoid gather such many properties in a single class that i require such tools for visual grouping....

Norbert

[Intaris]

I'm going to team up with Tst here.

It is possible to create huge clusters in LV.  Sometimes it's simply unavoidable and -shock horror- some of us know when to do which.  Sometimes it's event he most efficient way for one reason or another.

So given the fact that this IS something which people could use, what objections are there to a cleaner organisation of a data entity?  It has no effect on the internals of LV and maybe even making it a development-time only representation (as such would not affect the  UI code of Run-Time LV) would be an option?

Shane.

[zenthoef]

Wow... I didn't come in to work on Friday, so I am suprised to see all the directions this conversation went while I was out! I guess I didn't expect this to be such a hot topic.

I probably should have given more information on what I am trying to do. I wasn't planning on using the cluster to organize data with a class's private data.

I have a type def'd tab indicator (meant indicator, not control in OP) on the front panel of my top level VI that changes what tab is displayed programatically. To handle the programatic transitions, I am planning to create a class to represent the tab control and where its private data is the tab indicator's value. This way I don't have to deal with updating the tab indicator via property nodes. I was planning on writing the tab value that should be displayed into the tab's private data and then reading it out to update directly to the indicator in a separate GUI loop. 

What Rogerlsaksson asked on Friday about looking to have a ctrl/indicator reference to the tab control in my GUI glass may make more sense for what I am trying to accomplish. Perhaps the tab class's data should be a reference to the tab control and its methods should be things like updating the tab's value or updating ctrls/indicators that live on the tab control. Will this lead me in a good direction for an OO GUI? Or do I have other options I am overlooking?

[Darin.K]

Go away, the other discussion was much more interesting! 

You do have another option, you can use a normal enum with values corresponding to the Tab Page labels which plays nicely inside a cluster.  You can right-click your Tab indicator and create a constant (not a control or you'll get another Tab).  Right-click the constant and create a control and then you can use this to drive the Tab indicator.

The reference is also a good way to go if you need a bit more flexibility.

[zenthoef]

---

@Darin.K wrote:

Go away, the other discussion was much more interesting! 

---

LOL...

Even though I started this thread, I was debating if I should start another post or not to cover my original issue!