Tomi Maila

Ben, You may want to take a look at OpenG Active Object Template(.opg) that is part of class templates I wrote for LVOOP. See OpenG Wiki for more details. Active Object Template is a template for by-reference objects that include a single VI that starts executing when an object instance is created and stops executing when the object instance is closed. The template is meant to be used with Endevo GOOP tool but you can simply create a copy of the class from within LabVIEW as well to use it in your project. Use VIPM to install the template to <LabVIEW>resource\OpenG\openg_object\class_templates. The template requires OpenG Object package to be installed as well.

QUOTE (Ton @ Jul 7 2008, 08:41 PM) I've used CamStudio beta together with Lagarith lossless codec. The audio sync sucks and therefore I don't use CamStudio to capture audio. I edit the videos with Sony Vegas Pro 8.

QUOTE (neB @ Jul 7 2008, 01:47 PM) I'm afraid you will need to stay unproductive for a while

I’m very excited to announce a new ExpressionFlow Studio video series that will concentrate on LabVIEW software development. The first episode Objects and Classes starts an ExpressionFlow Studio series introducing to LabVIEW object-oriented programming.

I think this is a Firefox bug where the browser has at some point failed to load the icon from LAVA and happens to use that particular moment to determine the icon for LAVA bookmark. For some reason Firefox doens't seem to update the icons when they change. I've seen similar issues with my Firefox. QUOTE (Aristos Queue @ Jun 25 2008, 05:16 PM)

Please post your code.

Static dispatching should be used for the initialization method of a class for high performance quickly executing methods executed more than ~ 100 000 times for methods you do not want to allow to be overridden for private methods for methods that do not contain class input terminal for methods you want to put inside polymorphic VI Dynamics dispatching should be used for cleanup method of a class for recursively called methods (even for recursive init contrary to what was said above) for all methods you want to allow child class to override for all methods you are unsure if child class could benefit from overriding the method Notice that you do not necessarily need to use dynamic dispatch output in dynamic dispatch methods. You can have dynamic dispatch input and a static dispatch output and a dynamic dispatch input wihtout any class type output. Normally you should use dynamic dispatch input together with dynamic dispatch output though. Use static dispatch output with dynamic dispatch input if you want a child class to return possibly other class type. See Aristos Queue's LVOOP Map as an example of this kind of metethods. Use dynamic dispatch input without class output if you want to clean up an object and the object is no longer valid after the method is executed.

Actually variants are faster as conversion to variant doesn't require memory allocation. Conversion to binary string requires memory allocation as all the items of composite datatype are moved to same sequential block of memory. Furthermore LabVIEW comes with a nice set of utilities to investigate what variants are made of; see vi.lib\Utility\VariantDataType.

QUOTE (Aristos Queue @ Jun 10 2008, 08:29 PM) This is not exactly a driver but very similar though.... We wrote a very general file format interface using LVOOP and wrote an implementation for HDF5 files. This we have been using for a year now but about two weeks ago we needed to add support for proprietary TIFF image archive format based on MS JET databases and collection of TIFF files. Writing a new plugin that implements the class interfaces took a few days. Now our application framework fully supports this new format and no changes needed to be made anywhere outside the plugin. For us, a file format plugin is a collection of LabVIEW classes in a lvlib library. We load the plugin dynamically at runtime based on the selected file format when writing files or based on the file extension when reading files. We have plans to write new plugins for various other file formats including TDM and TDMS.

QUOTE (Tomi Maila @ Jun 3 2008, 12:32 PM) It seems that the problem we had was much bigger than I thought. One class hierarchy keeps corrupting again and again. The origin of the problem is that I moved a highest class in a hierarchy into a lvlib library. As a result LabVIEW seems to have two different references to this class, one outside the lvlib and one inside the lvlib. It seems LabVIEW sometimes decides that the class is really not part of the lvlib and when it does so, all the hierarchy gets corrupted. I guess I've no other option but to go maybe a week back in my source code control regarding this hierarchy before I added the class to a lvlib. I hate that LabVIEW files are of binary format (including binary fields of class files) and that when something goes wrong with the compiler, there is no way to fix things manually or even investigate what is wrong manually to be able to report a bug. At the moment I cannot report a bug because I really don't know at which point LabVIEW screwed things up and how and I've no means of investigating it.

This swapping method actually sounds pretty nice as no new memory buffers are needed. At least as long as the buffers are not too big and we are not too close to LabVIEW memory limit (actually my team is very close to the physical memory limits all the time). Is there any way to access the content of the swapped memory buffer i.e. the buffer that used to be the output of To Variant but after execution becomes the input of "To Variant"? Hmm... I decided to make a test of using to variant in a loop (see below). It ended up crashing LabVIEW, which was something I was actually expecting...

I contacted NI. It ended up to be a feature as rolfk suggested. To variant works in-place by swapping the buffers of its input and output terminals.

Omar has raised up an important subject. Actually just today I encountered this issue with LabVIEW 8.5.1 where LabVIEW corrupted my class file because of a dependency issue where there was two classes of the same name in the project. It also appeared that LabVIEW file search algorithm that searches for missing files cannot locate class control inside class file but tries to locate it from a Windows folder instead. Naturally this fails and all class constants, controls and indicators in the project get broken. I didn't find any way to fix them so my project was ready for carbage bin. Luckily I do use SCC so only one day of work was wasted. I think it's important not to think that corruptions cannot hapen with certain LabVIEW versions. The truth is that complicated software such as LabVIEW can always fail and developers should protect themselves against these failures.

QUOTE (rolfk @ Jun 3 2008, 09:09 AM) Good idea. I executed the test. Both arrays stay in memory, the large and the small. So it seems using variants can result in memory consumption cumulation issues.

QUOTE (neB @ May 27 2008, 05:04 PM) I just wrote a blog post on this subject. See the discussion in this thread.

I've just posted an article Extending LabVIEW-built applications with LVOOP plugins with an example project to ExpressionFlow blog.

Hi, I'm wondering the mysteries of variant memory buffer allocations, as they seem to differ from what I would expect. As LabVIEW doesn't have memory manager, the buffers contain the data last written to them and the next data written to the buffer replaces what ever the buffer contained before. This is true for normal data types but doesn't seem to be true for variants. Take a look at the attached code. An array is created at each iteration of the loop every 5 seconds. The size of the array is either 10M elements every other iteration and the array is empty every other iteration. When I do not convert the array to a variant, LabVIEW behaves as I would expect; the old buffer get written over by the new buffer every iteration. This can be verified from the Windows Task manager. When the VI is stopped, LabVIEW doesn't do any cleanup but the buffer allocations remain as they were when the VI was running. When I added the conversion to a variant, LabVIEW seems to behave differently. When the big array is converted to a variant, LabVIEW reserves memory. However this memory never gets released, even when I replace the array with an empty one. Only when I call request deallocation node, LabVIEW seems to free the memory for the variant. Is this a bug or a feature?

QUOTE (netta @ May 27 2008, 07:44 PM) You can always download LabVIEW Professional tryout and test it by yourself. If you don't want to mesh up with your system, install it on a virtual machine. Tomi

QUOTE (neB @ May 10 2008, 06:19 PM) I changed my avatar a little yesterday...

Should we ask this woman(?) to design LAVA NIWeek t-shirt?

I think merging is not possible within llbs but I'm not absoultely sure. Anyway it's easy to test out, it either works or doesn't work. I think it's not a good idea to keep VIs in LLBs when under source code control. I wrote a guide on using LVMerge with Tortoise SVN, maybe you can get some help from it.

QUOTE (Yen @ May 25 2008, 10:40 PM) Can you add to the report that if you in the color dialog window press the more colors button, and press Cancel button in the more advanced color dialog window, the event gets still fired.

QUOTE (Aristos Queue @ May 22 2008, 12:13 AM) In wonder what is night club life in Austin like... "Isn't she good looking. A pity she has a purple dress. I guess we would have nothing in common anyway, I wear only blue and black."

Thanks all, I consider your suggestions and try to find up what suits best for our needs. Tomi