LabVIEW OOP
Code and tools that assist or enhance LabVIEW Object Oriented Development. All forms of OOP are acceptable. Templates, code generation tools, etc.
9 files
-
Interface Framework
By Daklu
Interface Framework v1.0.0
Copyright © 2009, Dave Snyder
All rights reserved.
Author: Dave Snyder
LAVA Name: Daklu
Contact Info: Contact via PM on lavag.org
LabVIEW Versions:
2009
Dependencies:
JKI's VI Tester is required if you want to execute the unit tests.
Description:
In object oriented programming, often a designer needs a class to include the behavior of two or more unrelated classes. Traditionally programming languages address this situation with "mulitple inheritance" or "Interfaces." Unfortunately, Labview supports neither. The Interface Framework provides a structure for giving your classes Interface-like behavior.
Installation and instructions:
Option 1 - Install the OpenG Package using VIPM. This will install the framework in \LAVA\Interfaces\_Framework. Navigate to the 'User Libraries -> LAVA Code Repository -> Interfaces' palette to use previously implmented interfaces. The 'Advanced' palette provides vis for interface implementers.
Option 2 - Copy the 'Interfaceable Class' and 'IUnknown Class' folders from Core\Source to the location of your choice.
Documentation:
The Core\Documentation folder contains the following files,
-Changelist.txt - Contains the revision history.
-Interface Framework.uml - Contains two class diagrams, one for the core framework and one for the Baby class implementation of the ISleepable interface, and a sequence diagram of the Interfaceable:GetInterface method. Use StarUML to view this file.
Examples:
Examples of implementing interfaces in classes and using the framework in applications can be found in the Sample Implementation or Unit Testing folders.
Known Issues:
No testing has been done with Interfaces that inherit from other Interfaces. Very little testing has been done with interfaceable objects inheriting from other interfaceable objects.
Acknowledgements:
Special thanks to kugr and SciWare for taking the time to look it over and provide valuable feedback. Thanks to Stephen Mercer for patiently answering my numerous questions and providing detailed explanantions. Thanks to the LAVA community for being willing to share knowledge and ideas.
Version History: (For previous changes see changelist.txt)
v0.12.0 - Nov 1, 2009 (Unreleased)
[Note - Public api has changed. Backwards compatibility may be broken.]
-Renamed Interfaceable:GetInterface to Interfaceable:CastToInterface.
-Renamed Interfaceable:RecoverObject to Interfaceable:CastToInterfaceable.
-Changed connector panes and icons for CastToInterface and CastToInterfaceable.
-Added context help text to CastToInterfaceable.
-Changed error message generated when CastToInterfaceable fails.
v0.11.0 - Oct 18, 2009
[Note - Public api has changed. Backwards compatibility may be broken.]
-The framework now follows a more intuitive model where the interfaceable object is "cast" into an Interface, operated on using the Interface, and "cast" back into the original object. This allows the framework to work with static, by-ref, and by-val data in classes and more closely follows Labview's data-flow model.
-Added Interfaceable:RecoverObject method. (Name is likely to change in a future version.)
-Changed connector pane of Interfaceable:GetInterface method to one similar to the 'To More Specific Class' primitive.
-IUnknown now has both protected and community scoped methods for SetTargetObject and GetTargetObject.
-Added by-val, by-ref, and static objects for unit testing. Added test cases for testing by-val and by-ref object. Added mock interface IInt and concrete implementations.
-Changed some banners and icons.
License:
Copyright © 2009, David Snyder
All rights reserved.
Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of the author nor the
names of its contributors may be used to endorse or promote products
derived from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY DAVID SNYDER ''AS IS'' AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL DAVID SNYDER BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
(INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
2,338 downloads
Updated
-
LVOOP Event Handler
LVOOP Event Handler v1.0.1
Copyright © 2010, François Normandin.
All rights reserved.
Author:François Normandin
Contact Info: Contact via PM on www.lavag.org
LabVIEW Versions:
Created and tested with LabVIEW 2009
Dependencies:
openg_appcontrol 2.10
openg_error 2.3
Description:
This is a package that provides the framework for a LVOOP Subscribable Event Handler.
Processes can dynamically register new events and list the classes that are allowed to subscribe to it.
Once a TopProcess takes ownership of the Handler, it manages a Global Stop event and a Handler Activity event to inform subscribers that a new event has been registered with the handler. All subscribers can then get a list of all the events they are allowed to subscribe to.
Everything is done through events with LVOOP LVObject as a backbone. The subscriber will then be free to implement its interpretation of the subscribe event content when received, by casting to the known object types.
Instructions:
After installing package with VIPM, refresh palettes if VIPM is not set to refresh automatically.
Use palette to find the LVOOP Event Handler. Select the Event Handler VI and drop it in your application.
There is a test program that shows how data is exchanged between three dummy classes. You can open the front panel
of the Event Handler to see what are the actual allowed subscribers for which event owner.
Known Issues:
Acknowledgements:
History:
v1.0.0: Initial release of the code. (2009)
v1.0.1: Fixed a wrong connection with the "Preserve RunTime Class" primitive where children classes were not considered as such when a parent class was passed.
Better error handling on Destroy Handler command. (Caused a code 1 error when event destroyed by owner prior handler command.
Added the Event Description string to the connector pane.
License:
Distributed under the BSD license.
Support:
If you have any problems with this code or want to suggest features:
please go to www.lavag.org and Navigate to the discussion page.
Distribution:
This code was downloaded from the LAVA Code Repository found at www.lavag.org
============================
How it works:
This framework consists of a FGV Event Handler that manages the interactions between publishers and subscribers to events. It consists of some commands that allow the use of generic LVOOP events.
It allows the owner to control a Global Stop command, which can be listened by any VI. Once initialized, any process can register its own events and choose which classes are able to subscribe dynamically to it.
A generic event notifies all subscribers to a change in the list of the events available, so that no VI needs to poll constantly to detect the new events or unsubscribe from events that are unregistered by its owner.
Commands:
1- Initialize Handler: The first VI to call the initialization takes ownership of the handler. All other calls before the handler is destroyed will return an error.
2- Subscribe: Default case. When a VI subscribes to event, it will receive a list of all events for which it is allowed to register. Then the VI can decide what it does with the incoming data on that event channel.
3- Register: Any VI can register an event refnum (LVOOP type) and decide which object types can subscribe to it. If no input is provided, or if LVObject is in the list, then all are allowed to subscribe. A notification is sent via the Handler Activity event.
4- Unregister: Any VI that owns an event can remove it from the list. A notification is sent to everyone that listens to the Handler Activity event to prevent the need for poling.
5- Global Stop: Only the owner of the handler can call a global stop. It is meant to protect the integrity of the program should a subscriber decide to play god.
6- Destroy Handler: Releases the command to any process that wants to initialize it. It also erases all events still registered. It can only be called by the Handler's owner.
***************
There is an example VI in the LVOOP Event Handler palette.
1,960 downloads
Updated
-
LVClass API
Copyright © 2008, François Normandin
All rights reserved.
Author:
François Normandin
--see readme file for contact information.
Description:
This code is provided to help manage labview classes.
By opening a reference to a lvclass file, this API allows easy access to Private Data Cluster, Description, Class version, Icon, Tags, Class Items List,
Ancestor Hierarchy, Addition and removal of files to the class, Copying and saving classes. It can be the basis for cloning a class, applying standardized
icons to all VIs in the class, accessing tags and descriptions or to follow different versions.
Dependancies:
oglib_file-2.8
Change Log:
1.0.0: Initial release of the code.
1.0.1: Correction of installer code (second copy operation reversed)
1.0.2: Expose "Element (Build)" to Connector Pane in "IncrementClassVersion.vi"
Known Bugs:
1- The "Close.vi" uses a merge error with the first error from a close reference. This will discard any error on input to the VI if there is an error from the close reference.
2,235 downloads
Updated
-
MessagePump
By mje
MessagePump v1.1.4
Copyright © 2010, Michael J Eggertson
Author: Michael J Eggertson
LAVA Name: mje
Contact Info: Contact via PM on lavag.org
LabVIEW Versions:
2009 SP1
Dependencies:
None
Description:
Provides a object oriented implementation of a message pump in LabVIEW. Message pumps are also commonly referred to as a message loops, event loops, or message dispatchers in other programming languages. In terms of traditional LabVIEW design paradigms, a message pump would be considered the consumer portion of many kinds of producer-consumer based architectures.
Installation and instructions:
Extract the attached zip file to a convenient location. The included lvproj file contains four examples that should give a good indication of how to get started using the MessagePump and supporting classes. Using the MessagePump in your own projects will usually only require you to add the class to the project.
Examples:
Four examples are included.
Basic Message Pump demonstrates a minimal implementation that defines a class which overrides only a single VI and provides a VI which uses the class. Parameters extends the previous example and demonstrates how parameters can be passed to and from a MessagePump. Progress Dialog demonstrates how a MessagePump might implement a user interface. Callbacks is an advanced example which demonstrates how one might implement a Callback. Known Issues:
None
Acknowledgements:
This is a simple LabVIEW implementation of an architecture which has been around for quite some time...
Version History:
v1.0.0: Initial release of the code, posted but never submitted to the CR.
v1.1.0: Inital lava.org CR submission.
v1.1.2: Added a fourth example demonstrating the use of Callbacks.
v1.1.4: Fixed a bug related to locking the MessagePump, StartLoop will now return an error 123 if the MessagePump is already in use.
License:
Copyright © 2010, Michael J Eggertson
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer. Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the documentation and/or other materials provided with the distribution. The name of the author may not be used to endorse or promote products derived from this software without specific prior written permission. THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Support:
If you have any problems with this code or want to suggest features: please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and search for the "MessagePump" support page.
Distribution:
This code was downloaded from the LAVA Code Repository found at lavag.org
2,508 downloads
Updated
-
By Ref Active Object Framework
By Kurt Friday
By Ref Active Object Framework
Copyright © 2009, Kurt Friday
All rights reserved.
Author: Kurt Friday
LAVA Name: SciWare
Contact Info: Contact via PM on lavag.org
LabVIEW Versions: 2009
Dependencies: None
Description:
This is an OOP Framework that allows the development of By Reference Objects
with the capability to also be Active Objects.
By Reference capability is achieved by wrapping a DVR of the Data Members in a LVOOP Object.
An Active Object is one that has its own background process which is launched when the object
is instantiated. Active Objects are useful if your object requires time dependent characteristics.
Examples:
By Reference Object Demo
Demos\BikeDemo\Src\BikeDemo.vi
By Reference Active Object Demo
Demos\PumpDemo\Src\PumpDemo.vi
Version History:
v1.0.0: Initial release of the code.
License:
### BSD License (http://www.opensource.org/licenses/bsd-license.php) Begin ###
Copyright © 2009, SciWare <http://www.sciware.com.au>, Author: Kurt Friday
All rights reserved.
Redistribution and use in source and binary forms, with or without modification, are permitted provided that the following conditions are met:
* Redistributions of source code must retain the above copyright notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above copyright notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
* Neither the name of SciWare,nor the names of its contributors may be used to endorse or promote products derived
from this software without specific prior written permission.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR
SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY,
WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE
OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
### BSD License End ###
Support:
If you have any problems with this code or want to suggest features:
please go to lavag.org and Navigate to LAVA > Resources > Code Repository (Certified) and
search for the "By Ref Active Object Framework" support page.
Distribution:
This code was downloaded from the LAVA Code Repository found at lavag.org
1,999 downloads
Updated
-
Password_class
Copyright © 2008, François Normandin
All rights reserved.
Author:
François Normandin
-- see readme file for contact information
website: www.monpapyrus.net/LabVIEW/index.html
Description:
Class for management of password objects. The object contains a MD5 encrypted password.
Methods are of two types depending on source of password. From non-encrypted or encrypted sources.
All vis are documented. There is an example VI that shows how to use encrypted & non-encrypted versions.
Encryption level provides a mean to recursively encrypt many times over, resulting in better security against
rainbow tables attack. Initialize once with Password_Create method.
[Non-encrypted source]
Source is from a dialog box or equivalent. The password is not encrypted at the moment the object is created.
Password_Create method will create a new object, encrypt the password and store it.
[Encrypted source]
Source is from a file or tcp-ip connection. The password is already encrypted at the moment the object is created.
Password_CreateEncrypted method will create a new object and store the password.
Dependencies:
Uses the following OpenG toolkits:
oglib_md5-1.6-1
GOOP3®
OpenG: <http://wiki.openg.org/Main_Page>
GOOP® Community Edition 2.5: <http://www.endevo.se>
Change Log:
1.0.0: Initial release of the code.
1.0.1: Readme modifications
1.1.0: Added encryption level and modified naming convention for dynamically accessible methods.
1,638 downloads
Submitted
-
Pointer System
By bsvingen
Author:
bsvingen - Bjornar Svingen
--see readme file for contact information
Description:
A set of VIs that creates and controls pointer-data pairs. The basic idea is to simulate random access memory and malloc()/free() by using one single LV2 style global. The data type must specified in "..\Pointer\Data Typedef\Data Typedef__P.vi", or it can be replaced with an LVOOP class for LV 8.2. The only restriction to the number of references is the physical memory on the computer. The global stores data in an Array and uses a separate Bool Array to control access and free/protect the data.
The "address" to the data is returned directly with no type conversion (int32). Basicly the LV2 global takes data as input, put the data in an array within the global and returns the index where the data is set. This index therefore becomes a pointer to the data, and can be used later to set and get data.
The upper 8 bits of the pointer is used as a counter that is incremented by one for each new "dispose pointer" call. The "Get" and "Set" function checks these 8 bits in the pointer with corresponding counter array and throws an error if they are not equal. By doing this an error is thrown when trying to use a disposed pointer. Thanks to JFM for the counter code.
Due to the inherent effectiveness of LV2 style globals and no type conversions, this method is twice as efficient as using queue primitives, see examples provided. Functions such as New, Get, Set etc can be found in the ..\Pointer folder. A project file is also provided for LV 8.x. A more general system that takes arbitrary types is called General Reference System and can be found on this Code repository.
In contrast to queues that can be regarded as synchronous references to data, this reference system is fully asynchronous.
Allocation and freeing of data is done dynamically.
Allthough this pointer system may at first glance have some resemblence to "classic" GOOP, it is by no means a GOOP system. This pointer system is best regarded as a normal LV2 global, but with the difference that it returns a pointer (index) to the data, and therefore can be used for an arbitrary number of data.
All the VIs in the library are documented.
Version History:
1.1.2
Fixed "dispose pointer" and "obtain pointer from pointer". Some other small fixes.
1.1.1
Updated the counter so it will increment at each "dispose pointer" instead of "obtain pointer".
1.1.0
Updated the pointers so that the upper 8 bits is uses as a counter. Using a disposed pointer will therefore create an error. Thanks to JFM.
Updated the allocation routine so 100 elements are added in one chunk. Thanks to JFM.
1.0.1
Updated this readme.txt file
Fixed a bug in "Obtain P from P" function in the global.
Added a placeholder VI (for easier conversion to LV7)
1.0.0:
Initial release of the code.
1,006 downloads
Submitted
-
General reference system
By bsvingen
Author:
bsvingen - Bjornar Svingen
--see readme file for contact information
Description:
An LVOOP class that creates and controls reference-data pairs. The basic idea is to simulate random access memory and malloc()/free() by using one single LV2 style global. The data can be of any type (including any LVOOP class and strict typedefs) and can be allocated in any order. The only restriction to the number of references is the physical memory on the computer. The global stores data in a Variant Array and uses a separate Bool Array to control access and free/protect the data.
The "address" to the data that is stored in the reference (LV Object) ,is the index in the Variant Array where the data is stored in the LV2 Global. By using Variant as the type, it is possible to get a reference to all types, and there is no need to manually change a typedef and possibly the names for every vi when more than one typedef will be used.
A small performance penalty is introduced due to the type conversions to/from Variant. However, due to the inherent effectiveness of LV2 style globals, this method is still 2-3 times faster than an equivalent scheme made with wrappers around queue primitives, but slightly slower than using queue primitives directly, (no wrappers around the queues, see example provided). For an even faster reference system, twice the speed of queue primitives, se the separate "Pointer System" on this Code Repository.
In contrast to queues that can be regarded as synchronous references to data, this reference system is fully asynchronous.
Allocation and freeing of data is done dynamically.
Allthough this reference system may at first glance have some resemblence to "classic" GOOP, it is by no means a GOOP system. The main purpose of the reference system is to have a fully asynchronous and fully reusable system for read and write access to one single instance of data in more than one place.
All the VIs in the library are documented.
Version History:
1.0.3
Added an example using queue primitives as references with no wrappers.
Updated this Readme.txt
1.0.2
Minor fixes to the New function and some text.
1.0.1
Added this readme.txt file + some small cosmetic changes
1.0.0:
Initial release of the code.
910 downloads
Submitted
-
Class Iconizer
Copyright © 2006, jimi
All rights reserved.
Author:
jimi
--see readme file for contacct information
Description:
This tool allows user to apply new icon templates to LabVIEW classes. New template is applied to each item inside the class. User can define which parts of the template is transparent so that the template can be overlaid on top of the existing icons.
Version History:
1.0.0:
Initial release of the code.
496 downloads
Submitted