create a reference typedef

[F._Schubert]

Hi all,

I'm looking for a way to create a .ctl typedef reference, like in the Config.ini VIs is done (LV 7.1). There must be some basic reference control (type integer), where I can insert a custom picture.

The idea is, to have some kind of action engine, with multiple instances of itself.

Felix Schubert

[tst]

Create a custom control and drop a data log file refnum control in it (from the refnum palette). You can now drop any data type you want inside the refnum control.

Of course, you can also edit existing refnums.

P.S. Why do you need a special refnum for an action engine? Why not just use a VI refnum?

If you want to go OO, there are various OO implementations (OpenGOOP, dqGOOP, Sciware GOOP, Endevo GOOP) and some of them do use these to represent classes.

[F._Schubert]

Thanx tst

editing an existing ref num was the idea that popped into my mind when waking up this morning, but I wasn't aware of the data log ref num. The usage of a VI ref seems also a nice solution.

At the moment I am playing around with various design-patterns to encapsulate data/hardware access, to find out which might fit best. There is no big code to be encapsulated, so I didn't want to go to OO implementation. It is mainly passing data by reference (like pointers in text-style programming).

One idea that came to my mind as well is, handling large data sets (clusters of arrays and so on) by passing a reference to a local variable/AE; might increase performance, but the main reason is, that they 'pollute' my FPs (non-GUI).

Felix Schubert

[tst]

---

@f. Schubert wrote:

handling large data sets (clusters of arrays and so on) by passing a reference to a local variable/AE; might increase performance

---

That would be a big no-no. When you use a reference to front panel control you create a copy of the data and you force the VI to execute in the UI thread and you will actually lose performance. LV does not really have pointers. The closest you get is refering to a data store by reference (which is what the GOOP implementations and your proposed AE by reference do).

When you pass your actual controls through subVIs, LV can optimize the memory allocation (under certain conditions) and avoid making data copies, which is the killer when dealing with a lot of data. I suggest you search DFGray's posts for his presentation on managing large data sets in LV.

[F._Schubert]

Hi tst,

propably I didn't put my idea clear, I didn't want to pass a reference of the control. My idea was to store the data in a functional global (oh, I wrote local) and pass the reference to the functional global along. I mean: not the data reference to the FG, but the FG's ref.
So when I have some kind of GUI-window, that needs that data (for block diagram), it is not passed via a (hidden) control (propably making a copy) but instead just an U32 representing the FG/AE.

Thanx for mentioning the thread about passing data, I will check that out later.

Felix Schubert

[tst]

I noticed you added the AE, but your "local variable" was what drew me to that conclusion.

Anyway, remember that if your functional global is only used for data store, you need to implement locking if you want to write to it from multiple places. Since you would probably want to encapsulate the locking, you would end up creating something similar to the GOOP implementations. In fact, it would be very similar to OpenGOOP, because that also uses reentrant LV2 globals called by reference as the data store.

Of course, if your FG has the functionality embedded in it, then that's another story.

[F._Schubert]

I actually don't need the GOOP locking feature. My data is pretty constant: configuration, recipe, test patterns ... that are only manipulated in an editor (so no race conditions may occure). The main issue ist, that they are nested, so I have a cluster of arrays of clusters of ...
I like that hierarchical design at that point (edit windows may pop up other editors), because its more cleanly structured, settings may be reused... But LV Front Panels get overcrowded and lame. Its not the size in kBs, but if an array at the root is resized, that resizing goes all up to through the tree (I guess), and the same goes for the overlayed drawing of the FP (during developement).
I also think there is a performance improvement if I want to access the data in several wire-branches, as ther will be just copys of the integers made exept the (data) branch to the final data set.

The pattern I use is inspired by the NI build in Configuration VIs (under File I/O), at least in my FDS I can have a look into them. And I liked the green refnum-wire and the Control-Design.

So here is the way to do (in short):
Customize a text ring (representation is U16 by default), in edit mode copy a pic from clipboard as the frame. To make a picture, the normal icon editor will do. Bring the frame to the front and hide all other things behind.
Now drop that text ring into the datalog refnum. Make that a strict type def.
One issue: not a refnum?.vi is not working with this, you need to make a VI on your own, see the Config.VIs

So, now I have gotten a really LV-style refnum.