LAVA 1.0 Content

After some more chaotic brain activity.... this pattern works. It's however somewhat more complicated to develop than a regular class and some limitations arises from the fact that public class methods need to be outside the class. So I have a suggestion for the future releases of LabVIEW which would make this pattern simpler. The trick is that if user could define the access scope of the class constant/control, then the user could force the class to be initiated trough the class "constructor" and the singleton pattern would be easy to implement without any external library embedding. This addition would also make it possible for the class user to force constructor calls when needed. A user could place private controls on front panel, but the VI wouldn't run if the control wasn't connected to an external buffer source (i.e. if the VI wouldn't called as a subVI). The user could also place private constants on block diagram. These constants wouldn't initiate a buffer but would only carry type information. A wire leaving from these constants could only be conntected to new kind of node terminals called "Type specifier" terminal. All sorts of typecast and unflatten functions would have this new terminal instead of the present "required" terminals. User could also define front panel terminals to be of "Type specifier" type, but then these terminals could only be conntected to other "Type specifier" terminals. Aristos, do you think you could implement this in a future release of LV. After all it seems to me quite powerful addition to the language Edit: Some more brain work.... your design pattern would also allow users to make pure virtual classes

Sounds great and even very simple to implement. Can we expect this to be implemented already in LabVIEW 8.2(0).1 Do you think there would be a default error code for error objects? Do you think it would be techically possible to unflatten a flattened object directly into dynamic dispatch wire? This would simplify my implementation a lot. When no errors are thrown all the catch nodes just pass the error cluster trough them and only execute a single case structure. If these catch nodes are of subroutine priority, the are indeed executed quite fast. Of course if they are dynamically dispatched, then they cannot be of subroutine priority. However dynamic dispatching of catch nodes is not possible currently so, performance is guaranteed. Performance doesn't matter in cases when error has occurred as long as it's reasonable. I think it is very hard to slow things so much that the performance wouldn't be reasonable.

An additional trouble may be pricing. In Finalnd, the operator I'm using have the following plans for GPRS/3G data transfer. 1

Elegant This way I think I can also force the use of class constructors.

Hi, I think I worked out something pretty cool today. LabVOOP doesn't natively support class typed errors. Nor does it support throwing and catching exceptions as most object oriented programming languages. I implemented ability to throw and catch exceptions that are class objects. When an exception is thrown, the exception object is flattened to string and stored to error cluster. When exception is catched, the error cluster is tried to unflatten. If unflatten fails, the error is propagated forward. If unflatten is succesful, error is catched and error cluster is cleaned. This way, exception handling very similar to other object oriented programming languages is achived. There are many advantages in class based exceptions over the conventional error cluster. First, you are not limited to the error number to fully describe your error. Indeed you can store anything into your error class and that anything is available to you when you catch the error. Second you can use exception hierarchies. In the example attached I have an exception hierarchy. File error is a child of IO error which is a child of general error. When File error is thrown, it can be catched as a file error but also as a IO error or general error if you don't have an error handler for file error. That is you can write very specific error handlers but also very generic error handlers to handle unhandled exceptions. The exception technique is not perfect, but it is functional and seems to work quite well. It doesn't cause much runtime overhead unless exception is thrown, and in this case it doesn't really matter. What would be really needed is a wizard that lets you fast create a new exception class, would OpenG community be interested in writing one? Currently writing a new exception class requires defining a constructor and a catch method for the class. Constructor should call parent constructor. Catch method is of the same for for every class, but since LabVIEW doesn't support passing the dynamic dispatch wire trough unflatten string node, catch method cannot be inherited from ancestor classes. Additionally there may also be a class probe and other methods in any error class. Download File:post-4014-1157401108.zip

I've to correct you. Smartphone is generally defined as a phone device which has an operating system that allows third parties to develop software. Java support is not enough, the OS must support native third party applications. From this perspective all Symbian devices are smartphones. Anybody can write native software to them. Most symbian devices have much more functionality than PDAs or smartphones running Microsoft platform. I agree that they often look like phones, but that's because people also use them as phones. Take Nokia N80 for example. You have support for WiFi, GSM, GPRS, UMTS (3G) and BlueTooth networking. You have USB connectivity. You have web browser, email client, voip client, still camera, video camera, camera phone, video player, mp3 player and last but not least a normal phone. There are lots of third party software, take a look for example My Symbian website. I'm just curious to know, what there is in your definiton of "smarphone" or "PDA" that for example Nokia N80 doesn't have. -jimi-

LabVIEW classes cannot be placed on a block diagram by selecting "Select a VI..." from functions palette. Neither can one place classes on front panel by selecting "Select a Control...". In both cases a file browser that opens claims to accept LabVIEW classes. When one selects a LabVIEW class, a beep sound is played and nothing happens. Edit: I noticed that all my classes belong to a library. It may be that this bug doesn't apply to classes outside libraries.

This is really weird.... Can I trust my LabVIEW to compute correctly after bugs like this and the constant loop bug?

This may also be a feature, you never know what NI engineer intend when they make their design decissions. Class probes can access to private data members of the class. However class probes cannot access private or protected member methods of the class. Workaround is to make methods public, but then the methods will also be visible to class user which really spoils the idea of private and protected methods.

LabVIEW links to wrong context help. If there are many VIs with the same short name but different long name, wrong context help may appear. The image below describes the problem.

I submitted newer version to Code repository, it'll appear there as soon as one of the forum adimins has accepted it.

The number of Windows Mobile devices sold world wide is perhaps less than 1% of Symbian devices sold so your reasoning doesn't add up. Amount of Symbian users is also growing much faster than that of WM users. Perhaps NI just has strong trust in Microsoft in this field

Does anybody have any knowledge if NI has any plans to supporting Symbian mobile phone platform, especially Series 60, the most popular of the few Symbian alternatives. There are currently more than 80 million symbian devices sold and the number is increasing rapidly at exponential rate. I see two evident use cases. First remote controlling LabVIEW software running on some remote server so that the mobile phone would act as a remote control tool. LabVIEW for Symbian would make writing wireless remote control software easy and straight forward. Second mobile phonses could be used as wireless data acquisition devices. No additional computer would be needed if the measurement software could be ran on the mobile phone itself. USB cable or Bluetooth connection could be used to connect the acquisition card to the mobile phone. Of course LabVIEW for Symbian would need to include the driver for the acquisition card and mobile phones need to be charged all the time. However phones consume so little energy that an external battery would keep data aquisition up and running for long times, so not even electricity would be required if somebody just periodically replaces the external battery. There would be number of telematic machine-to-machine applications that waits for an easy to use development environment. It would be extremely easy to write for example a logistic software for a transportation compnay with LabVIEW for Symbian.

I already noticed that I can create and open projects, libraries and classes using invoke nodes. But to create the classes at the position I'd like, requires either that I write a project tree control of my own and let user to select the position. Alternatively if I could somehow add a new item to the right-click menu of the project browser which I could catch in an event case of a process running in background. The first alternative is laborous and the second alternative isn't there as far as I understand. My main duty is not to write class wizards but scientific software, so I probably need to stick with what others can provide. p.s. When I was walking outside, I noticed that I made a bug in the latest version class iconizer, the mask is computed incorrectly so that practically the color mask doesn't count. I'll post later the corrected version to the Code Repository as Michael_Aivaliotis suggested.

Hi folks, I decided to rewrite the whole program. There are only few new features. The biggest change is that I cleaned up the code very very much. I have encapsulated everything inside classes so that all components should be somehow reusable and intuitive. I also use extendible factory (design pattern) to create new objects so that support for new decendent classes can be added without touching the present classes. This was more or less a kind of an excercise to get aquinted with LabVOOP. The package may also be good to check out for LabVOOP newbies to get acquiainted with LabVOOP and OOP in general. The few changes are listed below All icons are automatically derived from 256 color icon, so it's enough to edit the color icon There is a new button which clears all icons (owerwrites icons with template icon) Hmmm... Interesting. Could I use those VIs not only to create custom class icons, but to create a custom class wizard, that is executed when ever a class is created? This could allow me to define a set of predefined project items I could select to add to the library and, well everything. So the question probably is if I can anyhow get access to the referense of the class library being created. Can I? Edit: I forgot the ZIP Download File:post-4014-1157220204.zip

It means number of rows of pixels. If your mask color is white and you use white text in icon header, then the header text wouldn't be copied. Therefore you can define the header height in number of rows of pixels, so that the complete header is always applied. In addition all the pixels that are not of the mask color will be copied from everywhere else except header. Asking is defenitely easier, the code is really ugly. I coded it in a hurry and for just one purpose only. Perhaps later I'll add some more features later on and clarify the code: Inheriting overloaded VI icon from parent class VI Automatically generate color16 and monochrome icons from color icon Automatically applying color for the frame surrounding icon; red for private and blue for protected (user defineable colors) Allow user to select library items to include / exclude Store settings to file

File Name: Class Iconizer File Submitter: jimi File Submitted: 4 Sep 2006 File Updated: 22 Oct 2006 File Category: LabVIEW OOP (GOOP) 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. Click here to download this file Download File:post-4014-1157146666.vi

Look in the Advanced File Functions pallete, you should see "Seek". Pass in your file refnum along with your position before performing a write, using the same refnum. To avoid race conditions, be sure to wire the Seek refnum out and error out cluster from Seek to the Write... (I'm at home today, and I'm not sure if the primatives for the file I/O palletes have changed with 8.0 / 8.20.)

Wire level reentrancy New issues seem to pop up. It seems that each class has only one instance of each member method data space. For reentrant methods there is a separate dataspace for each reentrant instance of the method. However dynamically dispatched methods cannot be reentrant. There is defenitely a need for reentrant dynamically dispatched VIs, Aristos Queue already said earlier that NI is trying to solve this issue. Dataflow OOP has however raised a need for totally new kind of reentrancy, that is wire level reentrant VIs. NI chose to implement OOP in dataflow ideology resulting in LVOOP. In traditional dataflow, wires carry only data. However in LVOOP wires carry also methods and functions. The problem is that in traditional dataflow each wire is totally unrelated to any other wire. In LVOOP wires may share same methods and functions as well. This raises new kinds of problems. If on one wire a method is called, then all the other wires of the same type have to wait for this method to exit before they can call the same method. This problem can be solved by allowing dynamically dispatched methods to be reentrant in classical way. The other problem is that shift registers and front panel values become global to the class. Sometimes this is a desired result but in may cases this defenitely is not what programmer wants. Traditional reentrancy would make shift registers and front panel values local to some node on block diagram. This may also be a wanted result, but in a dataflow thinking one may also want the shift register values and the front panel control values to flow with the wire. That is when ever wire is branched, also copy of each VI dataspace is created. This wire level reentrancy is totally new kind of reentracy for which there was no need before dataflow OOP. In this ideology the dataspaces of selected class methods would flow with the wire. Of course the compiler may choose not to copy the dataspace if it is not used or copy only those parts of the dataspace that may be modified elsewhere. Please NI, pimp my next version of LabVIEW to include wire level reentrant methods.

What do you mean by this exactly. Where do you need to use the array? The best implementation always depends on the details

UML is very fast to comprehend where as reading pages of text is slow and still you may miss the point. I think UML would be even more important than the text. Drawing the most important classes and their relation is not a big task. If you use something like MS Visio to draw the UML and include these drawings in a word document, you can update the drawings in a few seconds if you change the class structure of the pattern. I think UML is a must for design patterns.

Edit: Completely rewritten to clarify the message. Hi, I wrote a by reference objects template using two separate queues; one for the private class data and the other for locking mechanism. The private object data is defined in a private typedef instead of the Class Private Data control. The class template also contains a constructor, a destructor and a copy-constructor. The consturcor should be renamed to Create Class Name. If there are multiple constructors, all the constructor names should begin with Create Class Name. The copy-constructor and destructor are named Copy and Close respectively. The responsibility of constructors are to initialize the queues, initialize private data members if needed and call parent constructor if class is a child class. There are five private methods: _Init, _Get Data, _Set Data, _Get Data to Modify and _Set Modified Data. All private and protected methods start with "_" to indicate that they are not public. Also red color should be used in private method icons instead of black to indicate that the methods are private. The _Init method is used to initialize the queues and is called by the constructors and the copy-constructor. _Get Data and _Set Data are used to get and set the private data without locking. _Get Data can be used even when the object is locked; it returns the current state of the private data. Also _Set Data can be used even when the object is locked, but it's primary use is to store intermediate values to locked object when the lock cannot be yet released. There is however no guarantee that the data written with _Set Data will not be overwritten before the lock is released. _Set Modified Data can be used to release lock and to simultaneously store modified data retrieved with _Get Data to Modify. All the private methods are reentrant to ensure that there is no VI level locking; that is private methods can be simultaneously called from different sources even though the object is locked and there are private methods currently waiting for the lock to be released. There is however no way I can think of to guarantee that VI level locking doesn't happen to public dynamically dispatched methods. First only single instace of each private methods is used in each of the public methods. That is if there is a private method waiting for lock to be released and this private method has been called from a public method, then this public method is locked for all the objects since no object can access this private VI simultaneously. There is therefore VI level locking which I don't think can be avoided easily. The same problem is propably with all the other concurrency control methods proposed here. A ZIP file containing a LV 8.2 project is attached. The project contains two libraries. The first library contains the template and the second library contains an example how to use the template. I think also inheritance can be worked out, but I haven't tried it yet. I'll investiage it later either tomorrow or next week. I hope this helps people to get forward with by-reference objects and also clarifies why I have very strongly requested the addition of built-in constructors, copy-constructors and destructors. This example wouldn't work without all these. Download File:post-4014-1156620139.zip Edit 2: There are a few items that still needs to be worked out Inheritance Clean up of member objects at time out and at object close, propably separate private _CleanUp routine should be used in all methods If class Close is called during simultaneous call to _Set Modified Data the data queue may be empty. How to avoid this situation? Ability to create named objects, the same object can be referred in multiple places without joint wire source. Named queues will be used instead of unnamed ones. This would make it very easy to create Producer - Consumer design pattern. How to avoid VI level locking, is there any workaround? Can the template internal methods be somehow encapsulated into another class so that the implementation of the by-reference objects in general is not tied to the implementation of each individual class. This would allow updating the by-reference system all the time without need to update all the classes using the by-reference system as long as the interface to the by-reference system stays the same. VI level locking may be a difficult problem with this kind of approach. I appreciate suggestions to the above mentioned questions.

Hi, I wrote a Counter class, in which each instance of the counter acts like a by-reference object. So I decided to post it here. The counter class is based on storing the counter value in shift register. When an object is created with constuctor, a VI reference is obtained for storing the values counter in the shift register of that VI. Forked wires refer to same VI and therefore represent the same counter object. There is also a copy-constructor to create a separate copy of the wire that doesn't refer to same object. By-reference objects need to be closes with destructor method to close the used VI-references. In principle the class can represent any countable object for which +1 operation, reset, set and get can be defined, although now it uses only I32. Download File:post-4014-1156596876.zip

I would greatly appreciate LabVOOP design patterns. However you Aristos mentioned in another post that LabVOOP that it's currently hard to know which is the best design since the language is so new. So I don't think that a fixed document can do the thing, LabVOOP design patterns will evolve for some time until we the community understand what is the best way to implement different things in this language. So instead of document I'd appreciate a kind of online design pattern library. Each design pattern should include name of the pattern verbal description of the pattern UML of the class hierarchy images clarifying the central parts of the code (png not jpg) example code as a zip packages discussion forum about the pros and cons of each design pattern in slashdot style, everybody can comment and suggest new design patterns but only the moderators can add new design patterns to keep the quality of patterns

I've to give it a try another day. I found a frustrating bug when I tried to make a copy of my class structure which prevents me from going on today. The project file gets corrupted and LV crashes when adding my class hierarchy to a new library (lvlib). I posted the bug report to NI techical support as well as to here.