Mads

Gave up the downloaders and downloaded the giant file with FileZilla instead. Probably, I've never seen any platform ISOs on the NI-site...it would be greatly appreciated if they did start to publish platform DVDs, having to wait for the physical ones is boring, and should be unnecessary these days.

We've never experiences any VISA problems from shut-downs...but if the software required actions to be done prior to quitting, I do not think the application instance close event would do the trick, it does not seem to fire when the service is quit from the services panel. Does anyone have a way to filter/intercept such an event and run shutdown code? PS. Uou should also have RunAsService=True in the executables ini-file so that the service ignores any user logoffs (see http://www.ni.com/white-paper/3185/en).

And remember to vote for: http://forums.ni.com/t5/LabVIEW-Idea-Exchange/New-build-option-Service/idi-p/943246

Platform ISOs? Have they ever done that? I've always missed having such available. Normally they just post individual components and we have to wait for the platform DVDs to build a proper installer for our VLM... The driver DVD is out though. There are downloaders available too, but they always seem to fail right at the end, at least from any of my computers.

We've converted most of our applications into services on regular Windows (95/Vista/7/8) targets using srvany, and they work without any modifications. Are you sure the app works properly in the first place, before being converted into a service? Does it rely on access to configurations e.g that it might not have access to when it starts up as a service? If that configuration file is expected to be in a system folder the servic emight not refer to the same folder...) The link you posted talks about VISA server, not the VISA-RunTime...and it's the RunTime that's needed for the service to access a local serial port.

Every now and then I try using an XControl.. and get annoyed by its limitations. Graph annotations is another example... I just used the IP-address XControl here from the LAVA repository - it is a great use case, but the fact that you cannot tab out of this XControl like with other controls breaks the consistency of the GUI. I have not tried to get around it by modifying the code, but found a page on ni.com that says it's not doable. Is that really the case? Silly...

We use terminal servers for this all the time. Moxa, Advantech, Digi and Westermo. The virtual serial port drivers that come with these devices never (the ones from Digi might be the exception) handle network connection issues gracefully. If the network goes down for example, the drivers will freeze - and this can cause VISA to freeze or crash. However, if you use raw TCP/IP connections and write your own client (VISA has in-built functionality for this as well...I'm not sure if that's robust though), then you can make all of them work nicely.

I've tracked down the crash that came after upgrading to 2012 SP1(f1); it is caused by an add-on installed with VIPM. Clearing user.lib on its own did not fix it, neither did moving things out of the project folder. But when I removed the add-ons from vi.lib the crash stopped. The funny thing though is that if I then just put back the stuff from user.lib the crash returned. So maybe there are multiple items crashing LabVIEW (both in user.lib and the other places)...I'll do some more digging.

After upgrading first to SP1, then immediately applying fix 1 - LabVIEW is no longer able to run without crashing with an access violation: "Access violation (0xC0000005) at EIP=0x00EFD480" A common/known issue, or was I just "lucky"?

If it's there as you say; Have you tried to open the front panel of the VI with an invoke node in the built application? If you do that you can hit the broken run-button on it (as long as the front panel was included) - and it will tell you why it cannot run. That's often the quickest way to troubleshoot dynamic VIs that refuse to run in the built app.If nothing else the feedback you get this way is quick and typically verbose. Have you tried copying the code and saving it in a VI with another name - and calling that one?

As the error says; the path is not valid, and even if it was fixed, you are not allowed to dynamically call VIs included in the application file this way, so you need to put it in an external folder and generate the path to that location. However, if you do not need the VI to be replaceable after the build then you could also just load it into memory by including it in a case structure where it will not be called. Put it e.g. in a true-case and wire a boolean control set to false to the case selector (before 2011 you could have used a false constant, but now such unused cases will be stripped out by the compiler, with a control they are not). With the VI forced into memory like this you can call it dynamically by wiring the name of the VI as a string to the Open VI function.

No such error when I run it (3GB files even). I removed the wait function altogether. Running LV 2012f3 32 bit. It's not just an update issue , if you hit F5 or reopen the directory the OS has not updated the number to its correct size? Does it happen on a number of different files and sizes (above 1 GB)?

This is the reason I've suggested the following idea... Solving this smoothly with external code will definitely be a challenge, and it might not be possible at all - at least not without introducing behaviour that will seem weird to the user.

How does an update of OpenG like this progress? Is there anyone who will start to evaluate putting any of the suggested improvements into an official release at some point?

I really hope they include it in 2013, or better yet, in a service pack. The longer it is allowed to be as it is, the harder it will get to get it changed I guess. And the more code we'll see using it, with bad performance as a result.

According to the LabVIEW 2012 Features and Changes it does not preallocate: Note The Conditional tunnel option performs memory allocations as often as the Build Array implementation. Therefore, just like with the Build Array function, National Instruments recommends you consider alternatives to the conditional tunnel in portions of your application where performance is critical. And a quick test I ran just now indicates the same; its performance matches that of a continuous build function. I think a change in this behaviour is planned for LV2013.

The Tree_ShowScrollBar.vi sets each item as the active cell and calculates the width of its string. However that cell string is just the "Left cell string", not the item's full "Child Text", so it fails as soon as there is an item with such additional text.

Thanks. Managing the vertical scrollbar is relatively simple. It's the horizontal part that gets a bit tricky , at least if you have the rightmost column set to be "infinitely wide" and/or do not want to show the next (empty) column. If that was not the case I could use the same approach and use the "Number of columns"-property. Instead I'll probably need to calculate the width of the text in each column - and compare the widest item on display with the width of the tree. Not unlike how the mentioned vi.lib-VI does, but taking all columns into account.

Has anyone made a VI that will show or hide the vertical and horizontal scrollbars of a tree control depending on whether they are needed or not? I've done one myself for listboxes, and though there was one already for trees (it's hidden in vi.lib\tree\Tree_ShowScrollBar.vi), but that one does not seem handle cases where the children have more than one text item. (You basically end up with those items invisible).

Personally I would say it's not established enough to be intuitive to the user. But hey, if the users of this particular app expect it to work that way, then that's great. The general rule though should be that if it is possible to implement in a more established way then do that. You can always add a non-standard way as a second option for people to use if they prefer it, but not as the only option. A lot of people have the habit of trying to change GUI behaviour to something "better" - ignoring the fact that the cost of forcing people to change their behaviour from what they know and expect is huge - and seldom worth paying. That's why I asked the question of what the goal with the right-click menu is in this case. If the goal should turn out to be achievable in a more standard way then that should be prioritized over the perhaps "cooler" alternative (Not knowing the use case here the standard way might even turn out to be the coolest).

If the right-click is only supposed to work if it is on the selected page, do you really need to detect which *tab* was clicked? You can just assume that if the tab control as a whole was right-clicked then that is a right-click on the current page. No need to fiddle with finding out if the user for some reason hit another tab just to not react to it. Any right-click will lead to an action related to the current page. That is probably easier for the user to comprehend than if the right-click in some cases just does not give any response. Again - this would also be consistent with other GUIs - which do not react to right-clicks on tabs, but might have a menu associated with the tab page or control as a whole.

What functionality are you trying to achieve? Are you are dynamically building shortcut menus for the tab (not the page) that is right-clicked? The value of the control will tell you what page is currently selected, but the selection has to be done with a left-click first...If you right-click on the tab itself and expect a tab specific reaction then tab controls in general (non LabVIEW apps included) will normally not respond to it. So perhaps the best thing is to not build a GUI where the user is expected to do such a thing. You could alternatively place transparent controls above each tab to replace and expand the in-built behaviour, or hide the tabs and just use buttons shaped to look like tabs. Not as elegant as getting the info from the tab control itself, but off the top of my head that's the options I can think of.

That's quite common. In 2012 you can now define an executable to run when the user uninstalls your application; that idea was first posted by yours truly, then by Jim Kring. (Mine was marked as a duplicate because the latter one got more popular (pictures pictures pictures!)). Neither of them are credited in the 2012 release, nor marked as completed (it is a bit early after the release perhaps though) . Inlining is another example back from LV 2010. It has been marked as completed now (although the implementation is not exactly as simple to use as I envisioned it) - but was not credited because it was conceived independently of the Idea Exchange. It is only natural that we share a lot of the same ideas/needs.

Are there any new features we can utilize for the array toolkit in 2012? The conditional tunnel VIs for example will still be nice to have in 2012. As the upgrade notice says: "Note The Conditional tunnel option performs memory allocations as often as the Build Array implementation. Therefore, just like with the Build Array function, National Instruments recommends you consider alternatives to the conditional tunnel in portions of your application where performance is critical."

In an ideal world we would always jump to straight to the optimal solution, but if that's not an option it is still better to get something rather than nothing - unless that something is just a fraction better - but good enough for NI not to bother coming up with anything better after that...