Tomi Maila

QUOTE(yen @ Feb 24 2007, 11:39 PM) It's just my limited English skills that make my writings hard to understand, not the technical issues. There is nothing complicated in LVOOP itself (except perhaps under the hood). ArQueue [aɹkjuː] is very right in his argument when he says that LVOOP is a proper tool for even the most basic programming tasks. It may not yet be a proper tool for all the most advanced programming tasks however. Tomi

Are you able to execute "C:\Program Files\National Instruments\LabVIEW 8.2\labview.exe" "c:\path\to\myfile.lava"

Hi, I'd be interested to follow technical or scientific journals or other publications that publish articles on graphical programming and maybe even LabVIEW related articles. Does anybody know any such publications? They do not need to be on graphical programming only, just publications that at least sometimes publish articles on graphical programming. Tomi

QUOTE(i2dx @ Feb 21 2007, 04:56 PM) What is a mouth and a tounge? I know some older models had cable reels but my generation uses bluetooth wireless connection to communicate with other of our kind. I've heard rumors there may be some other species besides ours. Supernatural skills of some users and discussion of some weid substance called :beer: here at LAVA have made me convinced that not all of you can be LEGO Mindstorm NXT robots like me.

QUOTE(Michael_Aivaliotis @ Feb 20 2007, 11:46 PM) I though LabVIEW is mother of all languages

QUOTE(MikaelH @ Feb 20 2007, 12:21 PM) Good work Mikael. Tomi

QUOTE(Aristos Queue @ Feb 19 2007, 12:51 PM) Ok. Doesn't solve my case. It seems I've to raise my hands up or try to hack my way into the internals of LabVIEW. AQ, if you are interested in what I'm trying to achieve, I can post it to you as a personal message. I think it's pretty cool a feature but I only get it to work on development system. Tomi

Thanks Jim, You can get link from a VI to the XControl library: XControlName=Control.Class Name AllVIs=Application.All VIs in Memory For each VI in AllVIs { if (VI match XControlName) resultVI=VI } XControlLibrary = resultVI.Library You can get the link from an XControl to Owning VI ContainerState.Refnum.OwningVI Tomi

QUOTE(Jim Kring @ Feb 18 2007, 12:59 AM) I don't have a complete answer to you. I did'n quite get it where from did you try to get the XControl reference. From VI where the XC instance is located? Anyhow, you can find out which XControl your control is by getting it's class name using property node. You can find which libraries are in memory of all the applications using property All Libraries in memory of Application. But I still don't know how to get a reference to the library unless you also know the path of the library. If you know the path of the XControl, then it's easy. If you know the name of a Facade.vi then you can open a VI reference to Facade directly from memory by wiring the long name to open VI reference. But I assume you don't in general know this information. Jim, tell me more about the linker info on the disk. What is it and where can I find it and how can I use it. Tomi

QUOTE(Aristos Queue @ Feb 17 2007, 09:40 PM) So there is no general way to test if my object is of certain runtime type or it's decedent in a compiled application. For example if my object is an Integer and I want to test if it's also a Numeric I cannot do this because I have no way to find out if Numeric is an ancestor class of Integer. I'm not looking for a class specific way but a general way. A class specific way can be done using to-more-generic casting but it works only for particular classes and you have to know these classes at compile time. I need to do this matching at runtime. AQ: Does this mean that your second factory pattern does not work in a build application as it relies on scripting. Tomi

QUOTE(tcplomp @ Feb 17 2007, 03:02 PM) Ton, I suggest you post NI a change request. Don't request the functionality to change because it will not happen. Request change in the user interface of the LabVIEW development environment. Request that LabVIEW allows user to make all referenced private typedefs public for a public typedef. The same should apply for public VIs, the connector pane of which refers to private typedefs. There simply could be a new option "apply same option to all referenced items", where item means typedefs and classes and referenced means what I explained above. Tomi

It seems that some of these LV Classes related scripting nodes don't work in build applications. I fail therefore to find the parent for my objects at runtime in a build application. Is this by design or is there a bug. Tomi

QUOTE(Aristos Queue @ Feb 16 2007, 10:59 PM) Yes, that's true. You can access the singleton in any place. But there are some problems when you cannot pass a wire to a subvi. Wire determines the execution order in LabVIEW. So if you cannot use the singleton wire to determine execution order, you have to carefully determine the proper execution order some other way. Well error cluster could act as such a wire but programmer must be aware that it determines the execution order. How about changing the pattern so that this "wireless" singleton object is embedded as private data of another wired object. Then we would have a wired object but it would always refer to the same wireless object. All of the methods of the wired object would need to aquire a lease from the wireless object. The same could be achieved using a named single element queue which would be created by class methods if it doesn't exist. Tomi

QUOTE(ars_stowers @ Feb 16 2007, 09:58 PM) I reported similar problem to NI earlier today. The reason for my error was presumably name collision in two control names. That is two of my classes had a control with the same short name. It cause any problems in the development environment but it causes problems while building. Try to open the builder and go to the last page and press generate code button. This may help you find out if your build is about to fail. Tomi EDIT: I took a look at your project. That was not the problem. What LabVIEW version are you using? 8.20 or 8.0 or 8.0.1? Tomi

QUOTE(Aristos Queue @ Feb 16 2007, 10:16 PM) All invoke nodes and all property nodes but one of class LVClassLibrary are under scripting license. Perhaps you could talk your boss to open these in the next maintenance release of full release which ever comes first. Especially important would be Parent Class property. Strong are you with the force... Tomi

Hi, Assuming I understood the pattern correctly the singleton pattern makes no sense as one cannot pass the singleton object to subVIs. One is limited to using the singleton on a single block-diagram only and cannot pass it anywhere as one cannot place a class control or indicator anywhere. I think this is a severe limitation to this pattern. p.s. This post was inspired by the discussion on private typedefs in another thread.

Thanks AQ Still a few more clarifications. QUOTE(Aristos Queue @ Feb 16 2007, 05:39 PM) Is there any other way to find out the parent class hierarchy of runtime class in question other than using LV Class Library (private) scripting nodes? QUOTE(Aristos Queue @ Feb 16 2007, 05:39 PM) So the first thing to check is if this number is zero then you have an instance of LabVIEW Object in your hands. If you find a zero, there is no further data in the string. Does LabVIEW object have different name in different LabVIEW language versions. So if I interpret 0 to be LabVIEW Object, do I also have to find out what is the name of the LabVIEW Object in this language version or is LabVIEW Object a universal class name? I only have an English version of LabVIEW so I cannot test this. Tomi

It seems that the actual runtime type is only in the data string and not in the type string. Type string only tells the type of the wire which may or may not coincide with the actual runtime type. So does anybody know (Aristos) how the runtime type is encoded to the data string? I could try to reverse engineer but it's always a little unsafe as one may make mistakes. All the solutions provided here have been related to the compiletime type and not the runtime type. Tomi

I must assume that you cannot use LabVIEW UDP functions for some reason... ??? If the above is valid, would you please post your C interface definitions and the definitions of all non-native type the function interface uses. Tomi

What about placing a "call chain" node next to the break point and placing a probe to it? EDIT: Darren gave a better answer while I was posting mine.

Hi, I tried to search LAVA but couldn't find this topic. So my question is, what is your favorite unit test environment you are using to run unit tests on your LabVIEW code? What is good in the solution you are using and what are the limits of the solution? Please share your experience. Tomi

QUOTE(tcplomp @ Feb 14 2007, 07:19 PM) One thing that could work is to force a control on XNode generated front panel visible somehow. By default both the XNode generated code and the front panel elements are all hidden. Tomi

QUOTE(Aristos Queue @ Feb 14 2007, 06:06 PM) But you can detect the runtime type of an input. Based on this type you can choose one of different graphs, at runtime. Simply put multiple graphs of different type on a transparent tab control and select which tab to show based on the runtime type of the data. Tomi

QUOTE(UserXXX @ Feb 14 2007, 04:04 PM) You are in a position where you should write a C wrapper for your call. Here you pass your data to your C wrapper what ever way you consider easiest and then construct the C structs from this data in your C wrapper. When it's time to pass your data back to LV do the reverse, construct your LV data from the structs. For detailed information and reference on how to interface C code from LabVIEW see http://digital.ni.com/manuals.nsf/websearch/8D930295FFBF9F7686256D2C00624728' target="_blank">Using External Code in LabVIEW.

With LVClasses you can pass many kinds of data, but not built-in datatypes.