LAVA 1.0 Content

I think by-value objects and by-reference objects are logically different but of equal importance. Because of this logical difference, there is also a need to have a class hierachy difference between these two groups. As I have understood current LabVIEW Objects are all by-value objects. This has been explicitly stated in when LV 8.20 was released. This also means that there may already be many applications and libraries that rely on the fact that any object of class LabVIEW Object is a by-value object. So the meaning of current LabVIEW Object cannot be easily changed, the name however can be changed to correspond the meaning. By-reference objects and by-value objects also behave differently. By-reference objects are not copied when wire is branched whereas by-value objects are copied. By-reference objects can be passed to Java and .NET methods (in the future) and by-value objects cannot. Later on NI development team may be adding methods that are specific to by-value objects and different methods that are specific to by-reference objects. If there wouldn't be separate LabVIEW Value Object and LabVIEW Reference Object classes, this wouldn't be possible. Consider you would like to have a method toReferenceObject as a member method of class LabVIEW Value Object. If LabVIEW Reference Object would derive directly from existing LabVIEW Object, this method would make no sense as there is not meanig of transforming a reference into a reference. A more detailed scetch of the class hierarchy is below.

Hi, I've been supporting NI choice for by-value objects in LabVOOP. I thought that there could be a transformation from by-value objects into by-reference objects and back. Now that I've used LabVOOP very extensively for many months, I've come into a different conclusion. First current LVOOP cannot handle trees and graphs or any similar complicated data structures easily or effectively. I also now think that the by-value <--> by-refence transformation may make things messy and complicated and decrease the readability of the code. As a result I no longer support it as an alternative for native by-ref classes. I've now a vision that both by-ref objects and by-value objects can coexist natively and we could still have backwards compatibility with LV version 8.20. Now all LV classes derive from LabVIEW Object class. This built-in class should be renamed into LabVIEW Value Object. Two new built-in classes LabVIEW Reference Object and LabVIEW Object should be added to a future release of LabVIEW. Both LabVIEW Value Object and LabVIEW Reference Object would derive from LabVIEW Object class. All by-value classes e.g. present LabVIEW classes would derive from LabVIEW Value Object class. All new by-reference objects would derive from new LabVIEW Reference Object class (see the attached image below). This implementation would allow both by-value and by-reference objects coexist. Present LV classes would work properly in the new system. The system would be effective performance wise, as the developer could create by-value classes when they are the most appropriate choice. On the other hand the language would be more expressive as by-reference objects can more easily express more complex data structures and refer to real-world objects as well. As an extension to this model, current built-in types could also be made classes. This would only mean that built-in value types would derive from LabVIEW Value Object and built-in reference types from /LabVIEW Reference Object. These classes representing built-in properties couldn't be override, would have no methods and the only way to access them would be using built-in operations and built-in controls as is the case currently. However having a class hierarchy for built-in types would allow writing more reusable and modular code easier. One could for example write a subVI that accepts all objects of type Numeric as inputs and returns an object of the same type. Native by-reference objects are needed to provide better interoperability between Java Virtual Machine/.NET framework and LabVIEW. Now LV can call .NET object, but .NET or Java Objects cannot call LabVIEW. This is a problem as enterprise applications cannot easily be integrated with LabVIEW. Message cross-posted to the dark side (NI forums). Jimi a.k.a. Tomi Maila University of Helsinki Research Scientist Bio-IT

I think it has something to do with java downloading and cookies. I had the same problem when I tried to post the control. I went home and logged into lavag.org; my hard drive thrashed a bit and the file attachments dialog was available. I then came to work in the morning and cleared my cookies and cache and the file attachments was available at work too. This is just my observation. I'm sure Mike has been tweaking the new installation while we've been trying to learn this new stuff...

Just don't want to make it too easy for our competitors to figure our techniques and tricks.

First option might be applicable, especially if the subVI would be put inside disable structure so that it doesn't affect runtime performance. Second alternative is not an option due to many reasons.

Hmm... this really isn't what I'd like to see happening when I'm distributing an application. Would there be any workaround that would hide everything?

Does this help? XControl and Demo inside the LLB. If you need to change the colors or general appearance, edit the facade vi. Download File:post-949-1165924820.llb

The project files are human readable, so you can easily generate these files with LabVIEW. Then you can call hhc compiler to compile your project file. Just give the project file name as an argument to hhc. Be sure you have added Hh.exe and Hha.dll to your path variable statement. You may want to take a look at Wikipedia article on HTML help: http://en.wikipedia.org/wiki/Microsoft_Compressed_HTML_Help CHM file info (not project file but compiled help file): http://www.speakeasy.org/~russotto/chm/

If you are considering LabVIEW related banner ads, I may be willing to see them. So put there an option for premium members to show/hide the banner ads.

I wouldn't mind a banner ad if this means that helps to keep LAVA up and running. If the banner ads were LabVIEW specific, this could also be a good way for LabVIEW software companies to market their toolkits etc.

Perhaps I should consider premium membership. I wonder if accountants at my work accept Paypal payments as official expenses, I doubt they do. I expect that direct credit card payments will not be available in the near future.

It seems that LAVA forum engine stores the exact time of joining LAVA, not only the date.

I didn't get license although I was writing an add-on and I asked NI for license especially for this purpose. Perhaps I didn't get license because I asked a license for XNodes at the same time with the emphasis on the latter.

Ok. I played around for a while. Now I can resize Windows Media Player in a similar manner to the picture control. There is still a small problem, that is the container automatically resizes to the movie size when it loads the movie. I don't now have time to figure out how to avoid this. I hope this helps and you can get forward by yourself. Download File:post-4014-1165522400.zip

I'll try two things: 1. The attached VI has an icon with the graphic I suggested before. Use it if this is your problem. 2. You may be looking for a way to increase the values of a waveform. You can do this a couple of ways. A waveform is a series of y values with a constant time, delta t. The example of the multiply function is actually valid. You can also 'attenuate' by dividing or subtracting a value from the waveform. You connect your waveform to one terminal and the value you wish to use to scale/offset each waveform y value to the other. The output terminal will contain what a modified waveform. Look for Waveform Scale and Offset under "Functions -> Programming -> Waveforms -> Analog Waveform" Download File:post-949-1165521725.vi Hope this helps, and best of luck....

I believe you would need a computer with dual video outputs, or two computers; one for LabVIEW and the other as the video source. I'm guessing from the description of the device that the RS232 interface is via the telephone style jack. If you've got a reasonably new computer, you should be able to place a second video card in it, or buy a dual-head controller to replace the one you have. If you want to control the output device with LabVIEW, you may have to ask for an API; the vendor seems to offer some sort of Phase-CAM software that allows you to control the instrument. You can look for drivers on the NI web site, but I'm guessing they won't exist.

All ready there, mate! Sigh, I did a search in the Members section, and noticed that there are only 34 individuals who have signed up Out of approximately 5,400 members I was reading the "Creating Passionate Users" blog the other day, and it made me think of LAVA. The entry is called "How to Build a User Community, Part 1" I would say that most of the points made are already in place on LAVA, although we do poke the homework hustlers and newbies for not showing a minimum of effort (such as a Google Search or providing some example code). The only obvious thing that seems lacking is the number of answerers. Maybe an automatic 90 day premium membership for reaching 100 posts would make the nice things more tangible, and get people to sign up as premium members...

Ok, I fixed the bug. The implementation now closely resembles OOP design and it can quite easily be transformed to any LabVIEW OOP alternative. Download File:post-4014-1165357328.zip

Fixed, no polling no more, still the same event based architecture. Interesting, I thought notifiers and event cases internally use polling to "check for mail" but they're based on something else then, most probably CPU interrupts. I can see that events are hard to use if you are not familiar with handling dynamic events. So I fixed my example by adding some documentation into it so that it can function as an example of general manager design. Here it goes, only for LV 8.0 and later as LV 7.1.1 cannot handle multiple event cases very well. EDIT: There is a bug in this version, the manager function doesn't exit properly if only stop is pressed and panel is not closed. There is no event for VI stopped running so there is no straight forward fix for this bug. The previous version I posted doesn't suffer this bug but it uses polling. The front panel VI must send some sort of message to the manager VI to exit, I just don't know yet which would be most elegant method to do this. Download File:post-4014-1165339236.zip

This one, so far....

It seems that Crelf has passed Michael as the number one poster of LAVA... Congrats crelf! :beer:

I disagree and as a proof of concept I wrote an example which simplifies the process of resizing a front panel. EDIT: I personally do not like to pollute front panels with anything extra. It's quite ok as your VIs are simple but when your VIs get more like applications, I think one should stick with extremely simple front panel VIs. In the example the logic for the time delay is removed from the front panel VI to a separate manager VI. More complicated processes can also be given to manager VIs in a similar manner. Using LabVOOP and especially Command Design Pattern one can pass Front Panel specific functionality to be taken care of a general manager function as well. Download the attached example and open MyFrontPanel.vi. The example is for LV 8.0. Download File:post-4014-1165329550.zip

Brian and Jim, Thanks. I try these out tomorrow, it's getting late here. Did you try if your solutions work if the class is embedded into a library i.e. the name is something like this: MyLib1.lvlib:MyLib2.lvlib:MyClass3.lvclass?

But you don't know the path to the class by just knowing the in memory name. And there is not such a scripting property I know of that would return "All Classes in Memory". Of course you can get "All VIs in memory" and then try to figure out which class each VI belongs and store them to some sort of set of all classes and then you can compare your class agains all the classes in the "set of all classes"... well complicated. Anyhow for my purposes I just would like to use the class name in a indicator that would be able to show at least some information of all the classes... Hmmm... there is this probe for objects. I wonder if it's implemented in pure G and if the block diagram is not locked...

I just wonder if there are many special cases that may affect the type string such as the class belonging to a library or the class being derived from another class etc. And later on when there are classes implementing interfaces and such the code should still work, and it may not if we are not certain about the special cases.