LV2015 Actor Framework ShortCut menu missing

[JohnG3k]

Hi All,

So to summarize the problem, I have just upgraded to LV 2015 and unable to create messages for my actors. When I right click on a public method of an actor in my project, I do not get the Actor Framework menu item in the shortcut menu. So I am unable to create messages. Following instructions at this link:

http://zone.ni.com/reference/en-XX/help/371361M-01/lvupgrade/labview_features/

I am using a custom Actor Framework library, with very minor changes from the original (added a couple methods, etc). 

I have created a test project with the Alpha/Beta template, using the default Actor Framework, and the shortcut menu item shows up properly there, and I am able to create messages in that project. So the problem is related to my project, not the LV installation.

When I right click on 'My Computer' in my project with the custom Actor Framework, I am able to select New->Actor, and get the pop-up to create a new actor. In this pop-up, in the 'Inherit from:' control, I select the Actor.lvclass file from my custom actor, but then I get the error message "This is not an actor. Please make another selection"

So it seems my custom Actor Framework is not recognized as an actor. Does anyone know how to fix this?

Some background:

This project originally started in LV2014. I created a custom actor by copying the Actor Framework folder from the LV lib folder into my project folder. Did a mass compile on the new AF folder, and then temporarily deleted the Actor Framework folder from the LV lib folder. I opened up my project, and re-pointed everything to the new folder when it couldn't find the files at the expected location.

This all worked well, and I have been developing off this custom AF without problem till the upgrade. I was able to use the Message maker tool, and it made messages nicely using the custom AF library in my project. I did not have to do any setup for this, the tool just automatically referenced my custom AF library one it was in my project.

After upgrading to LV2015, everything worked fine initially (I just compiled my custom AF library to 2015 code initially), but then decided to try and integrate the new AF supplied with LV2015 into my project, to take advantage of the DETT support.

I used a similar method as before, copying the AF folder and the AFDebug folder into my project, mass compiling, deleting the LV folders, and trying to re-point my projects. I won't go into many more details other than to say this took a whole week, and lots of banging my head on my desk! But finally as of 2pm last Friday, I now have the 2015AF and the new AFDebug library integrated into my project, and all files in my project properly referencing the custom AF, and all files in the custom AFDebug properly referencing the custom AF, and all files in the custom AF referencing the proper files in the custom AFDebug. There are no conflicts anywhere in my project that I can find, and I can run the project with no errors, and all unit tests pass!

Then I tried to create a new message. Created a public method for one of my actors, right click on it, and no menu item to create the message.

So now I'm stuck again...

I have also, re-populated the AF and AFDebug folders in the LV folder, but didn’t help.

I have been working with NI customer support, but so far no solution.

Thanks,

John

[JohnG3k · Accepted solution]

Well, seems I managed to resolve my own problem, but incase others have a similar problem, here is the solution…

Whereas with LV2014, all you needed to do was include your custom copy of the Actor Framework in your project and the message maker would make messages using that class, the LV2015 message making feature require a bit more effort to work with a custom AF.

This document (https://decibel.ni.com/content/docs/DOC-44157) discusses challenges faced with creating an Actor Framework PPL, and though it is not mentioned, it appears the same challenges (specifically the inability to access tools like the message maker) occurs when simply copying the AF library into your project.

So in a nutshell (as I understand it anyway), if you want to create a custom ActorFramework, it must be in a PPL, and you must include a token in the ini file to reference that PPL.  I have converted my custom AF into a PLL, added the token in the ini file, and presto, I can now make messages again!

The whole procedure, including how to get where I was above, is described nicely here: https://decibel.ni.com/content/message/124924#124924.

Some extra points if you are in my situation where you have an existing 2014 project... Modify your Actor Framework.lvlib in your project. You will need to add the other AF messages that are in the AF folder, but not part of the AF lib, and the AFDebub lib into your new AF library (everything needs to be in one library). Doing this in your project prevents linking errors in you project later. Create your PPL from this new lib in your project, then right click on that same new lib and select “Replace with a  packed library…”, and select the lvlibp you just created.

[justACS]

I'm glad you found *an* answer, but it is not the only one.  You don't have to use a PPL, and many customers would prefer not to.

The AF project provider (the tools that provide the right-click menus) only works with classes that inherit from the version of actor.lvclass that resides in vi.lib/Actor Framework.  I needed to do this because the scripting code behind the provider needs all actors to have certain features, and I need to hide the menu options when you are looking at non-AF project items.  (It makes no sense to allow you to make AF messages for typedefs, although you might get some very interesting and cryptic errors if I allowed you to try.)  I can best ensure (though not guarantee) this by insisting on using the code in vi.lib.

You customized your actor framework, and then parked the new version somewhere else.  You created actors that pointed to this special version of actor.lvclass.  But that actor lives in the wrong place, so I don't recognize it.

So, another answer (and a better one, if you don't want to use PPLs) is to replace the shipping AF with your custom version.  Make a backup first, please - stick the entire Actor Framework folder in a zip file or something.  Then modify the shipping code as needed.  The project provider tools will work with your new version, unless you change something they need.

We actually provided several experimental forks and unofficial upgrades of AF to the community over the years, and that's what installation looked like (though we did automate it, at one point).

I'm going to downgrade your answer to "helpful", and mark this one as helpful as well, just to show there are two paths forward, if you want to do this sort of thing.

[justACS]

Just as an aside, may I ask what modifications you made to actor.lvclass?  Also, is there a reason you couldn't have just made a child of actor.lvclass with your new features, and then had all of your actual actors point to that?

[JohnG3k]

Hi niACS,

Thanks for the clarification. I considered that other approach, but decided against it for three reasons:

1. ) Every VI in the actor framework has a message in it warning the user not to modify the VI because it will affect all users on this machine, and that we should save it in another location if we want to modify it. And of course you can’t just copy one of the VIs without affecting the others. So it seemed to me from this, the suggested best practice was to copy the whole AF to a new location and customize it there. Then if you have other projects that you are working on that need to use the default AF, they still can. And this seemed quite reasonable to me.
2. ) Having the custom AF in a completely different path than the project, makes uploading the project to source control not so straight forward. Rather have all the custom code in one place. Also makes it more difficult for someone downloading the code from source control. They can’t just download and run, they need to know that they have to copy the custom AF into the appropriate place on their machine, so just makes it harder for people to use the code in the future if I’m not around.
3. ) In LV2014 this approach didn’t cause any problems. I just copied the AF to a new location, and everything worked fine. And this project was started in LV2014

But I completely agree with you that the approach you outlined is also good, and probably the one I would have chosen if I knew how much trouble it was going to be integrating our custom AF into my project. I hope that in the future support for custom AF lib in a custom location is returned, because developing with a PPL can be a pain… can’t probe any wires in the AF!

To answer your other question, the modification was to implement an ‘Enqueue at Opposite End’ method in the Priority Enqueuer class. I am creating a State Machine Actor based on the idea presented by Norm Kirchner in his presentation titled "The rebirth of the state machine" at the 2012 NI Week,  that most other actors in our project will inherit from.

We were a little hesitant to implement this method, as it was so straight forward and easy to do, it seemed there must be a reason why it wasn’t included in the shipped AF (guessing that the priority queue gave the functionality that the ‘Enqueue at Opposite End’ normally provided, and the two of them together would create the potential for some very confusing code). But it was the only way around the problem I had, so went ahead with it, but set it to Community scope so it is only accessible to the State Machine Actor base class (However it is currently set back to Public scope as the community scope was causing problems when trying to turn the SM Actor into a PPL… need to resolve this still).

John