From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.
We appreciate your patience as we improve our online experience.
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for
Document Options
- Document History
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report to a Moderator
Document options
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report to a Moderator
Build your own experimental fork of the Actor Framework
This VI package is a meta VI Package. It does not install the actor framework, per se. Instead, it installs the files you need to build your own fork of the actor framework.
This meta package installs into LV 2011 or later.
It installs a copy of the Actor Framework into your "examples\Build Your Own Actor Framework Fork" directory, along with a .vipb file and the pre and post build configuration files. Make your changes in the "ActorFramework" subdirectory, then launch VI Package Manager, point it at the "examples\Build Your Own Actor Framework Fork" directory and ask it to build you a package. The resulting package will be an EXPERIMENTAL fork of AF version 4.3 for vi.lib for 2012 or later (yes, this means that you who develop your edits in LV 2011 won't be able to install them in your own user.lib unless you make your own modified package).
So now, those of you who have a great idea for modifying or extending the AF or who want to build custom debuggers or other tools can now roll up your own package file to share with the community. The package will have the same "package collision" protections that I've used for the MAIN and DEBUG forks, which keep two forks of the Actor Framework from attempting to be installed simultaneously. So you don't have to worry about building these. The package currently does not build any palettes because the AF has its own palette built into LV and I haven't yet put together a post-install tool for modifying that palette -- VIPM normally does not allow packages to modify palettes that are already baked into LabVIEW.
SAFETY TIP: In VI Package Manager, when you build your package, change the name of the package file to something custom so that we know the package is your package and not someone elses!
Enjoy!
Comments
Options
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report to a Moderator
08-15-2012
03:05 PM
Using NI Community Documents to manage all the forks and versions of AF is starting to look unruly. Can we please put this stuff in GitHub instead? Crowd development of open projects is its entire purpose for existence. Also, a public repo is hosted for free.
Options
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report to a Moderator
03-05-2021
09:07 AM
Dear Aristos,
is this approach still valid? I am asking since the post is form 2012.
Regards
Andrea
Options
- Mark as Read
- Mark as New
- Bookmark
- Permalink
- Report to a Moderator
05-25-2021
09:03 AM
Andrea:
Not really -- the AF changed substantially in LV 2014. If you want to use the old version, obviously you can, but you'll be missing a lot of parts and using the much more complicated API.
The basic idea of "create a new installer that uninstalls the previous files and installs new files" would still work, but if you start with this package for its distribution content, I recommend that you update it with the latest-and-greatest copy of the AF and fork from there.
-- AQ
