(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_188.8.131.52.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!
I've been using LabVIEW for a few years for automation testing tasks and until recently have been saving my data to "[DescriptorA]\[DescriptorB]\[test_info].csv" files. A few months ago, a friend turned me on to the concept of relational databases, I've been really impressed by their response times and am reworking my code and following the examples with the Database Connectivity Toolkit (DCT) to use "[test_info].mdb" with my provider being a Microsoft jet oldb database.
However, I'm beginning to see the limitations of the DCT namely:
No support for auto-incrementing primary keys No support for foreign keys Difficult to program stored procedures and I'm sure a few more that I don't know yet.
Now I've switched over to architecting my database in MySQL Workbench. Suffice to say I'm a bit out of my depth and have a few questions that I haven't seen covered in tutorials
Using Microsoft jet oldb I made a connection string "Data Source= C:\[Database]\[databasename.mdb]" in a .UDL file. However, the examples I've seen for connecting to MySQL databases use IP addresses and ports.
Is a MySQL database still a file? If not, how do I put it on my networked server \\[servername\Database\[file]? If so, what file extensions exist for databases and what is the implication of each extension? I know of .mdb, but are there others I could/should be using (such as .csv's vs .txt's) My peers, who have more work experience than me but no experience with databases, espouse a 2GB limit on all files (I believe from the era of FAT16 disks). My current oldb database is about 200mB in size so 2GB will likely never happen, but I'm curious:
Do file size limits still apply to database files? If so, how does one have the giant databases that support major websites? Questions (LabVIEW Specific):
I can install my [MainTestingVi.exe], which accesses the jet oldb database, on a Windows 10 computer that is fresh out of the box. When I switch over to having a MySQL database, are there any additional tools that I'll need to install as well?
I've got an RT project which I need to distribute the source code, My .lvproj contains multiple .lvlibs + deployment info for a cRIO.
I'd ideally like to create a distribution that includes the .lvproj file and also removes the block diagram of certain VI's in this distribution, if I can't do that I'd at least like to password protect some key VI's.
Options I've tried:
- ZIP file - this includes the .lvproj and all the RT info I need, but there is no way to add passwords or remove a block diagram.
- Source distribution - I can remove block diagrams, but I can't include the .lvproj file with my RT info.
I could go in and add passwords to every VI in my hierarchy that needs protection, but that will take a while, and I don't require the passwords in my development copy, just in the distribution.
Is there a way to do what I want?
I have dutifully been creating new Executable Versions each time I make any changes to my application and then creating New Installers with this new executable.
For the Installer I did not click on the "Generate" button to change the Upgrade Code in the Version Information category - the Installer does this automatically. ie. each new Installer had a new Upgrade Code.
Now each time I have run the NEW Installer version it automatically uninstalls the old version and installs the new version - all very nice and simple
But today I needed to go BACK a version so I ran the previous installer expecting it to automatically do the same thing, but it won't let me.
My questions are:
1) Firstly can this be done, or can you only upgrade to newer versions?
2) What is the "Generate" button for if the NI Installer generates a new Upgrade Code anyway?
3) How can I get the NI Installer to upgrade and downgrade and application?
I'm having an issue with a teststand deployment (Teststand 2013, LabVIEW 2013)
I have a deployment which deploys my LabVIEW project containing all drivers (classes and lvlibs) for use in my sequences.
In the deployment (LabVIEW options), I uncheck "exclude vi.lib", "exclude user.lib" and "exclude instr.lib" because the deployment should also work on an PC that only has runtimes and an operator interface.
The build finishes without errors but I cannot open the deployed project...
--> not on a development PC because it finds conflicts (XNodeSupport and some vi's in vi.lib picture.llb)
--> not on a runtime PC (file not found)
Did anyone else notice the same behaviour ?
Thanks in advance for your help, tips and tricks :-)
At first, i thought i had something to do with LabVIEW search paths (because I include vi.lib, it should not search for the vi's in the real vi.lib) but that didn't help...