Independent cursors on array of cluster of graphs (or work around)

[mkabatek]

Thanks for your reply. Got it.

[mkabatek]

Hi tst,

Please forgive my ignorance, I am new to LVOOP, and I thought I understood your direction to package the management of the entire thing into a class, however I don't quite get it. 

I have tried to move operations on the plugins into a single class, and updating the subpanels into another class, but I am running into the same issues. Could you please elaborate on how one might properly structure the classes as you suggested, as well as moving the event references.

I have attached my attempt to encapsulate the functionality into classes, but I don't understand if I am on the right track. Your insight has been immensely helpful and greatly appreciated.

Also I am wondering how you would characterize the 'level' of this type of functionality in Labview? Trivial? Advanced? Somewhere in between?

Anyways thanks again for you help.

[tst]

If you want to design a clean hierarchy, you need to take a step back and think about it cleanly. If you do, you might realize that the events aren't actually needed. They were only there because I used them to move the data around, but they're not needed if you use other mechanisms. Likewise, you don't need two classes - since the plugins and the subpanels are intimately connected, they should probably be managed together. It's also useful to understand that if something doesn't change there's no reason to bundle it back in.

Here's a quick mod of your code to demonstrate what I was suggesting. I'm NOT saying that this is necessarily a good way to do this (in fact, this code has all kinds of problems and being dirty is only one of them), but it is one way. I would personally probably try using the actor framework or something similar, because using the controls to send the data back and forth is not very robust and elegant. I will also point out that I didn't really test it. It may well have bugs (one bug I can point out is that you read the index before the event structure executes, so if you change it you won't get the new value).

I would definitely not consider this kind of thing trivial. While you can see that the code needed for a proof of concept is fairly simple, building a framework like this which is safe and easy to use is certainly something which requires a proper understanding of how LV works. Such a framework would have to manage multiple process running in parallel without creating race conditions and without allowing the user of the framework to make silly mistakes which would cause stuff to disappear. That would mean the framework would have to expose a clean API and take care of everything properly internally.

[mkabatek]

Hi tst,

I have started to explore the Actor framework, and feel pretty good about making Actors, and somewhat less comfortable making Messages. I would like to us the AF to accomplish this subpanel task. I have modified an example from fabric here: https://decibel.ni.com/content/thread/15491?tstart=0

This example abstracts the sub panel. Subpanels can be loaded as actors, but I would like to extend this to making multiple subvi in the same subpanel, and send messages to each actor within the subpanel. I modified it to simply use the the same process as custom ListBox mod. However I am not uses the 'Messages"

Can you suggest how I could accomplish multiple VI's in the same subpanel as Actors using AF? I have attached the modded example. The Sub buttons load the the abstracted 'sub panel' actors into the sub panel, however I'm trying to achieve functionality like the 'Add' button I have added to the example using Actors/Messages.

As always, any assistance is greatly appreciated.

[tst]

First, don't post the same question to multiple threads. It just wastes people's time. If you do, make it clear that it's a cross post and link to the other thread so that people can see if there was already a reply there.

Second, you're going to have to decide what the various components in your system are and what the responsibilities of each component are. It seems to me like you need each actor to have its own dynamic copy of the VI and that you need another actor which will manage the array of subpanels.

One option is to do what's suggested in the other thread and to simply send a command with the new subpanel ref to the actor and let it insert itself, but I don't like that, because I think the manager should control who goes into which subpanel when, so the other option is to flip it around.

You can do that by adding to each actor (or have them inherit it) a message which gives them the queue of the manager (you probably don't even need a message - just do it before you launch the actor), and then have each of them send the manager a message with "this is my VI ref, please insert it". You can also add another message to the subpanels manager class which would be "please remove this VI from your subpanels".

Does this help?

[mkabatek]

Hi tst,

Sorry about the double post.

That does help, and I almost have it working correctly. My only issue with the scheme you suggest is that when I generate a new 'plugin' Actor to pass to the 'subpanel manager', I for some reason cannot use the "VI Server Reference", to "This VI" (my current Actor) because it is not strictly typed.

If I use VI Server Reference and pass to the 'subpanel manager', the VI does not get inserted correctly (basically a blank vi gets inserted). If I use a static reference to the VI (strictly typed), that does not reference the Actor itself, it references a copy of the 'Actor Core.vi' for my plugin actor, but it does insert into subpanel array correctly.

I have attached the code (I know its sloppy). The main program is dataViewAF.vi. Press "Load Beam" to insert a 'Beam Actor' plugin into the front panel. The 'Beam Actor' is the plugin I would like to insert into the subpanel array, it should pass its own VI reference to the manager using a message, however I cannot figure out to make it work if its not strictly typed. The subpanel gets loaded with empty VIs.

Thanks again for your input. Once I get this fully working I will clean it up and post here as an example.

[tst]

I didn't go over the code too closely (one of the big problems with OO code in general and AF code in particular is that it can be hard to understand the code without an overview), but it seems to me you're mixing things up incorrectly, which is what's causing some of the confusion. Here are some comments:

1. Why does the subpanel manager inherit from beam? I would have expected it to inherit directly from Actor, as it's a manager of an array of subpanels, not one the plugins that go into the subpanels. The abstract subpanel plugin (which I think you're missing) would then handle the actual job of sending the request to the manager.
2. If you embrace the AF, you might as well do it properly. Generally, in the AF messages are the only way you use to communicate and the actor core is the actual VI that's running. That means you would have to create messages to pass data and use the built in stop message to stop.
3. Since the actor core is usually the VI that's actually running, you usually need a way to communicate between the message processing loop and the actual UI loop. There are some threads about this in the AF group.
4. I would suggest starting with a simpler piece of code, just to see that it works, and then making the more complex one.

I would expect it would look something like this:

1. Subpanels Manager class (inherits from Actor)
1. Actor core - this shows the actual array of subpanels (or this might be done in a separate VI like it was in the previous example).
2. Add VI (VI ref, Actor Queue) - adds a VI to the list and calls the update method, which fires an event to update the subpanels in the core.
3. Remove VI (VI ref)
2. Abstract Plugin Subpanel class (inherits from Actor)
1. Set Manager Queue - Called statically before launching and write the queue of the manager into the actor.
2. Send Add Request (VI ref) - Adds the VI ref to the data and then sends an Add request to the manager. This VI is actually called by the core of a child class.
3. Send Remove Request (same).
3. Actual Plugin (inherits from Abstract Plugin Subpanel)
1. Actor core - this is the actual UI of the plugin. It starts by getting its own reference (using the This VI node) and calls the Send Add Request from its parent.

Like I said, you could start along those lines with simpler code and see how it works, then build it up.

[mkabatek]

tst,

First, thank you so much for your help. I would like you to know I sincerely appreciate your guidance and support.

I have remade a simpler code based on the subpanels code from AF, as well as your initial subpanels code. I have it working, and it has the structure you suggested. I can now add multiple subpanels within a subpanel using the AF. I believe the code example I have attached to this post is working correctly, and for the most part properly uses the AF.

Now when you press the buttons it will insert a new subpanel of  your choice into the subpanel array. I did not implement functionality for deleting, however it should be an easy extension. Please see attached.

I do have a few outstanding questions:

(1) I can't seem to use the subpanel manager Actor Core itself to hold the array of subpanels. For this to work, I am required to have an external VI called subPanel.vi to hold the array of subpanels. If I try and use the Actor Core.vi of the subpanel manager this scheme does not work. Why is this the case? Please see UpdateSubVIs.vi method, under subpanelManager.lvclass to see what I am talking about.

(2)  Additionally the subPanel.vi must be strictly typed, otherwise the scheme does not work (blank VIs are inserted of the correct size). Why is this the case? I feel it would be nice to use an instance of subpanel manager Actor Core.vi as the container for the subvis. Otherwise to have multiple actors with subpanels arrays or multiple subpanel arrays in an actor, one will need to use a DVR of subPanel.vi, as you showed earlier in this thread (in the non-AF example).

(3) Using subPanel.vi uses a loop with an event structure to stop it, and doesn't use the built in stop, which goes against your point of using AF properly. I feel if I could use an instance of the subpanelManager's Actor Core.vi as the subpanel container (as an actor) it would eliminate the need for the subPanel.vi.

Either way, thanks again for your assistance, I have learned a lot from your input.

**Anyone reading this post, please disregard the code in the previous post, I have only been working with AF for about a week, and understand much better now from this example**

[tst]

I only made two modifications to your code to make it work - I added subpanels to the manager's actor core and I modified the update VI like so:

As you can see, it uses the core's VI ref instead of the static ref and it has a conditional index in the loop to keep only the subpanel refs.

After I made these changes and ran the main VI, it worked fine. The subpanels were shown in the manager's core and everything stopped correctly.

I'm not sure why the subpanel VI didn't work when it wasn't strict. I don't see a good reason for it and I expect it might be a bug.

[mkabatek]

Excellent, this is a nice work around, however I have found one problem. I can only dynamically generate the number of subpanels initially placed within the subpanelManager Actor Core.vi This is a problem because I don't want to assume I know how many subpanels will be used.

For example, if I place 3 sub panels in the Actor Core.vi, I can only dynamically load 3 sub vis, unlike the static method, where I can make an unlimited number of subvis. Is it possible to get around this limitation?