David_L

Oh no... If they changed the NIPM logo, that probably means LabVIEW is not far behind. It's just so.... green... Good thing our project is still stuck on LV2016 🙂

Hey all, (Cross-post from ni.com forums) We have a LabVIEW application, which has a LabVIEW-based Installer. This LabVIEW installer is called from within another Inno installer (since our main Inno installer pulls together multiple components, most of them not LabVIEW). Whenever this Inno installer ends, it always asks the user to restart their PC, even if the LabVIEW installer was cancelled. I narrowed it down, and it's reproducible with only the LabVIEW installer, so it's definitely LabVIEW installer's fault. According to Inno's help documentation, "if a program executed in the [Run] section queues files to be replaced on the next reboot (by calling MoveFileEx or by modifying wininit.ini), Setup will detect this and prompt the user to restart the computer at the end of installation." However, as stated above, this dialog is triggered even if the LabVIEW installer was cancelled and wrote no files. Now, the above linked documentation refers to a flag I can put in my installer script to ignore this restart dialog, but it's a global flag, and I would like my other installers to still make use of this handy restart dialog if necessary. Unfortunately it seems LabVIEW installers trigger this even if not actually necessary. Has anyone seen this before? Any ideas how to make my LabVIEW installer NOT muck around with the MoveFileEx or wininit.ini stuff if/when it's not actually needed? Attached is a LabVIEW project and Inno Installer script which easily reproduces the problem. To reproduce: Extract the attached .zip Open test.iss in Inno Setup and click the "Run" button Alternately, just run the built installer under "\Output\test_inno_installer_9.99.0.0.exe" Click Next on 'Select Components' dialog Click Install on 'Ready to Install' dialog When LabVIEW installer pops up click Cancel, then yes (you're sure) See the Restart dialog Thanks! David_L InnoLabVIEWBug.zip

Agree with Paul. Assuming that this is some feature that isn't supposed to be there, they'll support this in the way they support any bug. File a bug report that may or may not get fixed in a future version of LabVIEW (likely > 1 year away) then give you a workaround, which is don't use this unstable hidden feature. If it is a feature that is supposed to be there, but buggy, then pretty much the same result, as there's probably not much else they can do for you in the short term other than suggest a different, more stable approach.

For those who don't feel like crashing LabVIEW, here's what it looks like. It looks like something out of LabVIEW 1.0 that was somehow never removed. In my former role at NI dealing with all the secret features we didn't want the average user to know about, even I never came across this one before. Given this, and the fact that it crashes when you try to use it, I can almost guarantee you that NI will not be interested in providing support for this. Better to stay away unless you find some good reason you think you need it in your project.

Man, I need context...

Paging Mr. @QueueYueue, you have a telephone call at the front desk...

Nice! I recently became addicted to podcasts and was wondering if/when there would be any LabVIEW based ones. VIShots made one many years ago, but it isn't updated anymore. Subscribed!

If this page will be the forever "Landing page" then I agree you should delete the posts eventually. However, now that a wiki exists (whether in it's current place, or back here if Michael figures out a way to add a wiki), my thought was someone (you, me, someone else with free time on their hands) migrate your top post to the wiki and that becomes the forever "Landing page". That way, again, it's not only up to you to maintain it for eternity, but can evolve through community involvement over time. Agree or disagree?

@The Q I don't know how difficult it would be, but I feel like it would be 1000x more effective if the wiki was hosted on lavag itself. While I agree that a wiki is a good choice, having yet another place to go for LabVIEW content, might fragment the community even more. @hooovahh @Michael Aivaliotis Or any other Moderators, Do you guys have any insight if it's possible/easy to add wiki functionality to the Lavag site?

I second the Wiki approach. This allows everyone to easily contribute, without any one person having ownership of having to keep everything updated. There's way too many sources of content that are created and as soon as the content creator moves on to other projects it gets left in the dust, never to be updated again (I know I've been guilty of this on the NI Community in multiple places). Do you guys think a wiki like this should be under NI control (more visible and official-looking) or independent (unbiased and community led)?

Personally, I think that VIPM would cover most of the needs of code sharing if it wasn't for one HUGE limitation which is a public, free, open repository. The LabVIEW Tools Network repository is great for sharing code that has been vetted and approved by NI's engineers and processes. However there's obviously a huge need for a public repository that has little or no barrier to entry. And even if somebody created a repository like this somewhere (LAVA maybe?) nobody could access the repo unless they pay for a Pro license of VIPM per-user. Now what Derek/MGI have started with GPM is an awesome first step in solving this, but I think there's one big disadvantage: there is now one additional tool for installing G Code (reminiscent of https://xkcd.com/927/). If I have a project that uses some NI toolkits, some LVTN toolkits and some Open Source GPackage toolkits, I have 3 different tools needed for getting a system set up. I also have three different places (not counting the numerous GitHub repos, LAVACR pages, internal code repos, etc) to go looking for the code I need. What we need is a single tool that will install everything from all sources in the same standard. I would also want some way to differentiate what's an official NI product, whats a validated LabVIEW Tools Network product, and what is a use-at-your-own-risk open source ...thing... It would also be great if users could rate and review all these things so you could have more information on which of the 7 JSON toolkits is the best for your needs. I also realize the fallacy of pointing out problems without solutions, but as I'm not in the business of making package management tools, it's hard for me to prescribe others what to do with their time and money. Hopefully this discussion bubbles up to the right people who ARE in this business so we can get the solution the community needs. [Edit: Darn, in the time that I was typing this, it looks ShaunR posted almost the same ideas, just more succinct... Glad we're on the same page]

mxLvProvider definitely refers to some project provider code, and TSVN is almost completely a project provider add-on. The best bet in this case would be to uninstall TSVN and see if you still see crashing. If the problem points to TSVN you might be able to reach out to the developer, but since it's a free toolkit I don't know how much bandwidth they put into development and updates on it.

Darn, that's a bummer. Thanks to both of you. I did consider the option to use VI Server to automate these things, but that would mean creating a custom LabVIEW tool to replace something that already exists and our team is already familiar with. Agreed that there doesn't seem like a good solution, but maybe someone else out there will have some secret ideas that we don't know about :-) Thanks again, David

Hey all, Pretty obscure question here, hopefully someone out there has some ideas. Our testing team uses a GUI testing tool called Squish. You use this tool to record GUI interactions so you can automate mouse clicks, etc. For software written in other languages (for example, Notepad++) Squish will refer to an object by a name or ID. This allows the test to work no matter the resolution, location or size of the window. For example:. function main() { startApplication("notepad++"); mouseClick(waitForObject(":41001_ToolbarItem")); mouseClick(waitForObject(":41002_ToolbarItem")); mouseClick(waitForObject(":Open_Edit"), 312, 8, MouseButton.PrimaryButton); type(waitForObject(":Open_Edit"), "asdf"); clickButton(waitForObject(":Open.Cancel_Button")); mouseClick(waitForObject(":_Pane_2"), 318, 161, MouseButton.PrimaryButton); type(waitForObject(":_Pane_2"), "asdf"); } However for a LabVIEW application, Squish does not seem to assign any name to the controls(however window names are assigned), and instead refers to the object by relative location: function main() { startApplication("DavidApp"); doubleClick(waitForObject(":David_VI.vi_Window"), 38, 150, MouseButton.PrimaryButton); doubleClick(waitForObject(":David_VI.vi_Window"), 35, 199, MouseButton.PrimaryButton); mouseClick(waitForObject(":David_VI.vi_Window"), 183, 167, MouseButton.PrimaryButton); mouseClick(waitForObject(":David_VI.vi_Window"), 44, 37, MouseButton.PrimaryButton); mouseClick(waitForObject(":_Pane"), 45, 12, MouseButton.PrimaryButton); mouseClick(waitForObject(":David_VI.vi_Window"), 170, 224, MouseButton.PrimaryButton); mouseClick(waitForObject(":David_VI.vi_Window"), 470, 16, MouseButton.PrimaryButton); } So the question is does anyone know how to assign these Object IDs for LabVIEW controls? It seems to be defined by the application, not by Squish. Has anyone used Squish (or similar tools) for GUI automation of LabVIEW applications and had success? (Cross post on ni.com) Thanks, ----- David Ladolcetta Certified LabVIEW Architect Cirrus Logic

Nope, I didn't see it pop up at all, which is weird because I can see in the VIP file that activation is enabled. Maybe something weird with the version of VIPM I have (2017.0.0f1)? I know there have historically been a lot of weird issues between TPLAT and VIPM, so it never surprises me anymore when something weird like this happens.