bsvingen

Right clicking on an iten (a vi) in the project explorer gives a menu with an iten called "replace with..." This is extremely handy. But sometimes this item is greyed out, and I can't figure out why and what to do to un-gray it. Anyone?

There is no problem including external libraries, several of them, and keep them nice and tidy and separately when distributing the source (directly from the source distribution in the build). Maybe this problem only exist when distributing exe?

Yes, I have read all that, and that's why I am wondering. LGPL is supposedly too restrictive when used in a Labview environment.

I am wondering aboout what type of license to use. LGPL or BSD (or maybe some other). I have read through some old discussions here, but since they are 4-5 years old, maybe something has changed. BSD is recommended here, but it is not entirely clear why LGPL is not recommended. Thanks

Thanks. I just wondered, since the options can be hooked on/off even when inlined and I could not figure out why. For instance, if the compiler for some reason didn't want to inline the code after all, THEN the vi would be either a single clone or several based on the setting. Not much info about this. Also, "subroutine" for inline code makes no sence, unless there are som catches somewhere. So you are saying there are no catches, inline is inline no matter what and RT makes no difference.

In general, when inlining is hooked does it matter if you use share clone or preallocated clone? And then when using RT, the help files say preallocated is best, but what if you inline the code? thanks

OK, sounds good to me. With "ordinary" LVOOP I have to make dynamic dispatch vi's to be able to use get-set methods of data for the parents, (that's what I have been doing) . With these property nodes there are no longer any need to do that. Will this property node be faster execution vise than equivalent dynamic dispatch, or is it simply a dynamic dispatch (with all the overhead) in disguise?

I am wondering if they are correctly implemented, and if so will they stay this way. For instance, all descendant classes can use the properties of the ancestor class with no implementation whatsoever of the read/write vi's of the descendant classes. The other thing is that I can add code into the class property node, making it a sort of strange invoke node. Regards

If the UI and the "logics" can run separately, they are decoupled IMO. But decoupled does not mean void of interface, obviously there has to be some interface and some communication of data or there would be two completely separate programs (of course also decoupled, but irrelevant). A close coupled program has no real interface since the UI and the "logics" are woven together, as in a typical PC LV application. So decoupled means separate programs communicating through an interface. The two programs only have to know the interface.

We are developing on RT targets using cRIO and other embedded computers. The UI runs on a touch screen panel computer. This is decoupling in the correct sense IMO. The UI and logics run on different computers (kilometers apart), with different OS'es, in fact three OSes. The same architecture could also be used on one single computer with virtually no change in the code. The main point is that the UI is the "plug-in element", not the other way around. This is straight forward RT development using standard architecture learned at any RT course by NI.

Didn't see that... Thanks.

Is there an easy way to make a copy of an entire class (all methods)?

Excellent. Just now started with labview 2010 (SP1), and I find it slow and unstable. I remember 7.1, that was a good one, and 2009 is not so bad either. When is 2011 planned to be released?

Finally started using 2010 (with sp1). I find it somehow slow and unstable. One VI that was upgraded from 09 made the entire LV shut down, no info, no error message, it just shuts down labview completely. I found the error to be within a formula node that works perfectly in 09. 2010 also runs slower on win7 (32bit) than in xp, by a factor of 2 or more. I am just wondering if someone else has this experience, or are there some tricks in 2010? Right now 2010 seems like a bad batch to me.

Success, lvdiff at least The vital information was in that last pic, and at the VERY end of the readme.txt file in the lvdiff-folder. Thanks a lot by the way. Should be no big problem making this work in GIT either (edit:not true, there will still be problems with path names and stuff), but Mercurial looks and works much nicer in Windows anyway.

Looks to me that something is missing in the wiki? or the lvdiff tool ? I have no idea what readme.txt file you are talking about. I have placed the lvdiff in the c:\lvdiff,and have full read-write permissions.

The LVDIff.vi has a somewhat large BD. Where in the file am I supposed to insert your code? Another thing. I get an error when opening the lvdiff.vi. it complains about a missing ini file. Looking a bit closer, the lvdiff.exe is seemingly made in C++ (visual c project). The lvdiff.vi in there doesn't really do anything, and it will not run because an ini file is missing with unknown content. It is very confusing.

In setting up LVDiff, there is a snippet to be inserted into the code? or is it to replace the code, or am I supposed to make a new file? I don't understand where the snippet is supposed to go. Also, why not use LVCompare that is shipped with Labview?

Tried using GIT with LV, but gave up on understanding the ins and out of using LVCompare and LVMerge in GIT in a windows environment. So, setting up Mercurial now

I have traced the error to Listview.Create.vi IListViev node report Error 97 (Null Refnum). The “Value” outof AXCont is 0, even though the reference into it is a valid refnum. I am running Vista right now, maybe this has something to dowith it? Edit: It is the ListView ImageList that is an invalid ActiveX container (or dot NET?) "The Control could not be loaded" error.

He he, I thought I did. Anyway, it is not as much to change as it is stating the facts. LV is a software for the corporate streamlined marked where DAQ and control of expensive equipment is the heart of the matter. This is a niche (as far as software goes) where there is a lot of money in few units, particularly in hardware but also in software and software related hardware. NI products are tuned to serve this niche, and they do it with excellent results for the customers. Believing, hoping or wanting LV to be anything but that, is wrong, plain and simple. As an engineer and scientist I have been using LV on and off for 15 years or something, and I know that if I use LV I will get exactly what I want, and I will get it done every time, almost no matter what it is (certainly not as elegant as several virtuoses here, but still ). But, this doesn't change the fact that LV still is exactly what it is (as explained above). So, when the application starts to move outside the core niche boundaries, I will be alone. There will be no one to there to pick it up when I leave because no one knows both the application domain and LV sufficiently. If I had used Java or C the situation would have been very different, but even then I wouln't see a line of people. The other part is license. This particular application requires approx 5% of my time on average right now, maybe less. For me to pay a full LV license out of my own pocket, seems way out of line. I think I have explained enough how I ended up in this situation, and what should have been done to prevent it. But, the license problem may be solved very soon now, at least within a month. Nevertheless, I still regard this as the number one obstacle for more mainstream LV. Also, most programmers simply hate the idea that the LV luanguage itself is proprietary. Java is already diving into the embedded marked with much more reasonable licencing than NI. Finally, LV is an excellent tool when used inside its niche. Outside this niche it is also an excellent tool, but exclusively for those persons who already is working inside the niche. Licensing cost will prevent a change, because no one outside the niche will even dream of paying the license for something they perceive (right or wrong, it doen't matter) as a vastly inferior product for making general purpose programs.

But then again, it is also my code, and I am the one that talked people into going this route, licenses and all. All in all the only real conclusion to be extracted from this, is that LV is not the ideal tool for more general purpose programming (trying to be diplomatic here ). Yes, LV is tuned towards streamline corporate, preferably controlling/measuring expensive and/or critical equipment. Taking it outside that frame, and the cost and time benefits really do not add up. It is similar to an airliner. A ticket with an airliner to the US is cheap, probably the cheapest cost per km you can get with any transport. But this doesn't mean that airliners are cheap, or that you would get the same cost benefit travelling with an airliner to see a movie in a town somewhat close by.

Nice, and thanks. But it doesn't work. Not in Lv 6.1 or LV 7.1 It will not connect to the vi server. Everything is set as described regarding ports. The vi server settings report port 0, and when changing it, it still is 0 when trying to change it again. The ini file is set to 3363.

Not entirely. Although I agree with AQueue as a principle for preventing issues like this, what is going on right now is like this (remember, the license for "my" software is shared between me, A and B, and I only get paid by the hour for development) : My previous employer and B want me to continue maintaining the spreadsheet that they own and use, but they will not give me a license for Excel. MS will not even talk to me, even though I am sole responsible for selling them several licenses of Excel to B and making then continue updating their licenses.

The software is like a toolkit, similar to the PID toolkit or one of the simulation toolkits. LV Full development system is needed to use it. Although finished systems can of cource be compiled like any other LV software, this is more like a bi-product, but I have made some of those as well and sold them. I don’t disagree with A Queue. In hindsight I should have made it clear that B was responsible for my ”personal development license” and any licenses I would need for future maintenance and development. This would have prevented this mess. Nevertheless, policies are policies, and licenses are licenses. That is a fact. By using Java, problems associated with these issues will disappear altogether, that is also a fact.