Yair

Maybe it would be more practical to upload these to Youtube. It would allow you to have a higher resolution and would not put a load on the Tecnova FTP server. Mark, if you want, I can try helping with that.

I would personally love it if NI actually found a way to go the other way and to considerably increase the update rate (to the order of weeks) and make quick updates really easy. Ideally, this would solve the pain of having to install new LV versions, because you would simply keep updating your installed version. It would allow NI to deliver both features and bug fixes much more quickly. Alpha/beta users could test the new features and NI could use CEIP to gather usage data on new features. Those who don't want to get updates can configure the system not to do so. NI could designate specific versions as LTS versions and only release fixes for those. Of course, the big concern with such a system is how to avoid breaking things with all those updates and I don't have a really good answer for that.

We use SVN (and people have a hard enough time with that when there are conflicts or when a commit or update fails and you sometimes have to do various combos of manual and automatic cleanups to get back to a working state), so I wouldn't know. The main feature I would want from the DVCS world is the ability to have local versions which allow you to do convenient testing of features and I can generally manage that in the cases I actually need it with a bunch of annoying methods (branch, create a manual copy, commit and revert if needed, etc.). That doesn't give me enough of an incentive to want to transition to DVCS, so in my case the answer is "No, SVN is not so bad".

The method appears to accept any valid object reference, so when I typecast the pane ref to a control ref, it appears to work. This, of course, comes with the usual warnings about typecasting references:

Here's a very rough example of the subpanels way (2011). The actual mechanics obviously need to be made proper. The big advantage with something like this is that you can completely divorce the UI from the data, you can create arbitrarily complex behavior (because you're only dealing with one element) and that if you need to change something, you only need to do it in one place. The disadvantages are that you lose some of the edit time convenience (although that happens with other things too), that the code can be more complex and that you might have some more difficult with keyboard navigation. Array of subpanels demo.llb

It is actually sort of possible to create an array of subpanels. You can't do it directly, but you can have a VI with a subpanel which will itself have multiple subpanels and control that to look like an array. To this day I still never had an actual need for something like this, so I didn't work out the whole thing, but I did post a quick example here - http://forums.ni.com/t5/LabVIEW/User-interface-problem-list-of-clusters/m-p/2311770#M726599 I expect that the major issue here would be that you need to communicate with all the VIs, so you would need to come up with a mechanism for that which would still have an API which would make them simple enough to use.

You never know. Maybe it gives you an ulcer, and then it could also be abdominal...

I would strongly suggest NOT using Excel to save your data. Pick a method to save your data (examples include a simple binary file, TDMS, CSV files, databases, etc.) and if you want to see the data in Excel, export a copy of the data to a format that Excel understands. That way, your data will not be dependent on what the user does.

The RGT uses ActiveX, not .NET. There's a thread with Excel examples here, and I assume at least some of the newer ones are probably with the .NET API - http://forums.ni.com/t5/BreakPoint/Excel-Board/m-p/379682#M2391 Looking at your OP, I see that you're using the RGT. It has a VI which returns the Excel ActiveX references. You should be able to use that to get the Application reference and set it to hidden (I think there's a Visible property, but I didn't really play much with it, so I don't remember for sure that I even did this).

There was some discussion on this a while back on Tomi's blog, which seems offline at the moment - http://lavag.org/topic/17804-functional-dataflow-programming-with-labview/ You could try pulling a cached copy from Google or the Wayback Machine. That said, I don't think the discussion got very far on a technical LV level. My own understanding of functional languages is very superficial, but as I understand it, this is something that needs to be deeply engrained in the language itself. I'm assuming you could put together a crude implementation which would implement some of the basics of functional programming by calling VIs by ref and passing in arguments as key-value pairs, but I doubt it would be elegant or perform well. It reminds me of (I think, can't be bothered to look it up) an XKCD comic which had a caption along the lines of "functional programming combines the power and elegance of abstract maths with the ease of understanding of abstract maths".

Like I said, I never dealt with VIPM myself and Ton isn't responding to emails (championship went to his head? Blood went to his head on account of being upside down?). I tend to agree that it's likely that the conflict is the issue - looking at version 2.1.3.1, it doesn't have a conflict listed, so it would explain why it can be installed. I would guess that for some reason VIPM is ignoring the underscores in the name in some places and treating it as the same package, so it thinks it conflicts with itself. What's not clear to me is why this is happening only to some people. Maybe it is something else you have installed? Maybe it has to do with the version number of VIPM (although it was said here that this has been happening for a couple of years)? Maybe it has to do with the VIPM license, which runs additional code for different licenses? In any case, I think that it should be safe enough to remove the conflict now. I took the OGP files I had on my computer and manually removed the conflict line from the spec file and from the spec file inside the OGP file. I didn't change the version number and I didn't test that this works properly. I'm attaching these files here and they should be unzipped to <Users>\All Users\JKI\VIPM\cache. I would like to someone who knows where this can be reproduced to test it there and see if it's no longer happening. If it doesn't, we'll figure out a way to build a new package. Also, if someone has contact with Ton (e.g. on Facebook or Twitter), maybe you should contact him separately and nudge him towards this. lv-cct.zip

Also, yes: I really like that LV places a lot fewer restrictions on the names we can use for things than most languages.

Or learned to use the wayback machine - http://web.archive.org/web/20130329175236/http://www.developria.com/2008/10/project-management-from-the-de.html

I haven't read all the replies closely, but if I understand what you want correctly, you might also wish to look at the examples here - http://forums.ni.com/t5/LabVIEW/An-experiment-in-creating-compositable-user-interfaces-for/m-p/1262378#U1262378 AQ's example constructs the UI programmatically. Mine assumes that there's a UI for each specific class and opens a reference to it. Note that both are nothing more than proofs of concept. If you move ahead with them, you may find all kinds of issues.

There are APIs in LV for this, but creating the code necessary for this can also be tedious and you can read up on scripting to see this. I haven't really dealt with class member generation and so on (the relevant VI server class might have the methods and properties you need for this), but I suggest you download GOOP Development Studio from NI's site and look at the code. It should be open source and I assume that the parts that script the class are also open source. You could also try looking at the code in <LabVIEW>\resource\framework\providers (or similar), which is the code that actually does this, but I believe that is mostly or all locked.

I don't think I would want a break either, if only for two reasons: The "nanny state" argument given by PiDi. Sometimes you might want the race conditions. Possible mistakes by NI. We have seen cases where there bugs in the inplacer or other low level parts, and having something like this that breaks your VI and the only way to fix it is to find some way to write the code such that the compiler doesn't see it as a race condition is not something I would appreciate. I agree it's better than a bug in the inplacer, but I still wouldn't want to run into such a mistake. A warning of some sort, on the other hand, is definitely welcome.

I have no practical experience with something like this (or the relevant background to help), but one thing you might be able to do is place some wi-fi access points around and use an app on the phones to collect and transmit the data. I know that there are some apps which claim to be able to fairly accurately locate base stations (such as this one). I have seen one of them (don't remember which) used once and it seemed to be reasonably accurate in a single room with no obstructions. I have no other data points as to whether these are actually reliable and whether they have APIs, etc. I'm guessing that these use the signal strength to determine the distance (probably assuming no obstructions in the way, although I'm not sure how they would know the signal strength at the source), but I'm not sure how they determine the direction, as at least the one I saw seemed to be able to do it without moving the phone. In any case, you might be able to do this yourself using the phone's API to get the signal strength and then triangulating several base stations to get the position of the phone. I'm assuming the main issues would be walls and electrical systems which would change the signal strength and that you would need enough base stations to cover the entire area properly. Perhaps you can mount them fairly high. The water issue can probably simply be resolved with water-tight covers for the phones. Although it's probably simpler to get the location information as Shaun suggested.

Another possible option is to basically build your own palette VI and drop the things from there. You might need some playing around to get the instantiation and dropping correctly because of the instances issue. I don't think you can use the Application class method UI.Place Object on Cursor, because that accepts a path and you want an unsaved instance and a quick test indicates that using a VIT drops the VIT. You'll probably need to use the VI Activation event to remember the last active VI and then instantiate the VIT and add the reference to that VI yourself at some random point. You can probably then highlight and select it.

I think that the difference is that scripting never really had the problems that XNodes have. It had some holes and things that didn't work, but it was basically complete and stable. My understanding is that XNodes have some serious problems which NI plans on addressing by replacing them with something else. This understanding does not come from any official NI line or from a deep understanding of XNodes (I actually have little more than a cursory understanding of their actual structure which comes from playing with them a bit), but it does come from NI and it is up to date. I can't estimate how representative it is of what will actually happen, but it's not something that I made up. Something like this has happened before with external nodes, which were the 7.x equivalent of XNodes. They worked, and they did the same things as XNodes, but I guess they had issues which were too big, so NI replaced them with XNodes, and apparently it is their intention to do so again. All this does not mean that you should not use XNodes. They certainly can be written to function correctly. You should just take into account that even if you write stable XNodes, you might have to rewrite them in a few versions, because they will no longer be supported. Maybe NI will create some kind of migration option. Maybe not. Maybe they'll create a tool to assist with migration and publish it without support. Maybe not. Libraries can be nested freely (although I wouldn't be shocked if this caused some instabilities to appear) and I believe the only exception is that classes (and maybe .lvsc too?) cannot contain other libraries. I haven't checked with XNodes, but I believe they can at least be added to libraries.

And the documentation for LV 2013: So this also refers to the single queue and the peeking and doesn't mention other issues. I don't know if this changed at some point after 7.0 (e.g. in the 2013 refactoring) or if back then it was simply buggy. I agree that this doesn't appear to be as undefined as it used to be, but I still doubt I would go near it (unless perhaps it was an extremely simplistic case of something like multiple consumers configured to only handle event X and a stop event and even then probably not).

Actually, they do. You just need to change the filter in the file dialog to show them, but that won't help you, because they will still drop as VITs. I thought I have a vague recollection of a config option which does allow you to change it, but a quick search didn't find anything and I'm probably imagining it. A couple of other options: You could create an XNode which would replace itself when dropped. This will probably do exactly what you want, but if I understand it correctly, you will need to duplicate the XNode for every VIT, because I don't think there's another way to directly associate the node with the VI in the palette. This is similar to the express VI option, but somewhat more friendly. You could create a quick drop shortcut which will take the selected VI(s), instantiate an untitled copy and replace it. This is probably the least work. You could have a single VI which will create a copies of all the VITs that you want when run and then replace itself with all those copies (practically, it would probably have to launch another VI to do the replacing). Of course, that means that it would have to be statically linked and that you would have to delete the VIs you don't want.

The behavior I saw was different, but it was on 7.0, which was the first version to support dynamic registration, so the underlying code may have been different. I don't remember the exact details, and I don't feel like looking up the thread, but essentially it was something like "there are events waiting in the queue, but they're only processed after a timeout happens, even though the timeout case itself isn't executed" or "events sometimes disappear without anyone processing them". In short, inconsistent and unpredictable behavior, at least in that specific instance. I believe there were also cases of events sometimes being processed by more than one structure (the peek behavior you mentioned) but sometimes disappearing without anyone handling them.

Ah, I see. The phrasing was really confusing, because you made it sound as if it would behave in the same way. I personally think it's not as bad, if only because it wouldn't behave the same and that it does have a defined behavior. I wouldn't say I would recommend it, but it's not *as* bad. I don't think I would ever do that, because as far as I can tell, the behavior there is undefined. You might figure out how it behaves and use it as a hack, but undefined behavior is not something I would rely on (and in the one time I needed to be hurt by this before figuring out I shouldn't do it, I actually saw that the behavior was not just undefined, but also inconsistent, at least in the way I wrote that specific code. And in that case, incidentally, I wasn't even processing the same events. I was processing different events from the same refnum in separate structures). I also expect that almost every single programmer who splits this wire does it because of ignorance of the consequences.

Is it a fact? I understand how it that could be (we know that static events are registered as soon as the VI goes into run mode, so it would make some sense), but it would make just as much sense (more, in fact) to say that each event structure has a separate queue and uses the same mechanism that the VI would use to detect the transition to run mode and then registers separately. What makes you think that the VI has what is parallel to a single registration refnum? Also, thanks for posting this. I spent a few minutes earlier today unsuccessfully looking for the code from Jack's presentation for something and I figured I would have to look at the video tomorrow to find the link to the code there. Now in looking over the first page of this thread I found the link.

Ton appears to be AWOL and I can't seem to reproduce this issue. I hate shifting the burden, but can you check with JKI to see if there's an option to enable debugging or logging on VIPM and see exactly why this is happening on your machine? I'm seriously hoping that this is not the experience most people are having. I'm still suspecting that this has something to do with something else you installed first or something you have configured, but I have no idea what. The other alternative to figuring this is out is to remove the dependency. Like I said, I haven't dealt with the VIPM part and I also haven't personally dealt with the CCT code directly in a long time (my role in recent years has been more in feedback and design. Ton did most of the actual coding), and it's currently saved in Mercurial, which I don't even have installed. I would have to read the build instructions to figure out how to build it as much as anyone else would, and I don't know if I have the tools needed to build an updated version. Anyone who wants to can have a look here - http://sourceforge.net/p/lv-cct-tool/code/ci/default/tree/