hooovahh Posted December 3, 2013 Report Share Posted December 3, 2013 Lets say you have a set of customers that each have some version of LabVIEW run-time engines installed, but not sure which ones. You can't build a LabVIEW EXE to give to them because you don't know which one they have installed and if you give them a 2013 EXE but they only have 2011 it won't run. You could send them an installer with the 2013 RTE but that is ever growing and can be a pain to download when the customer isn't sure if they need it or not. Well my idea is to use AutoIt to get a list of the LabVIEW versions (development or Run-Time) and then choose to run a EXE built in a version that is compatible with the version installed. This means building your EXE in multiple versions of LabVIEW and for larger applications this may make less sense then just distributing the full RTE for a single version of LabVIEW. Attached is my source. Extract it and you have a Source folder with the project and VI that just reports the LabVIEW version and path. And a Builds folder which has the AutoIt source (au3 file) and the built EXE from the au3. This EXE should run on any version of Windows XP and newer. Then there is a folder of EXEs all built with different versions of LabVIEW but from the same source. When the AutoIt EXE is ran it finds a RTE compatible with an EXE that is included and runs it. In the zip is version 2011, 2012, and 2013 but to add others just add the folder and EXE named the same as the others. I wouldn't be surprised is someone like JKI or Wirebird Labs has done something like this in the past but I thought I would share what I have done anyway. My use for this is with a new and improved version of my LabVIEW Tray Launcher. It is assumed if you are using the tray launcher that you have a version of LabVIEW installed, but which one? I could distribute multiple versions in a single installer, and then have the shortcut launch the AutoIt EXE which decides which LabVIEW EXE to run. I haven't fully tested it but it appears to work properly. EXE Test.zip 1 Quote Link to comment
JackDunaway Posted December 4, 2013 Report Share Posted December 4, 2013 Cool utility! +1 ...Wirebird Labs has done something like this in the past... Short answer: the concept=no, the tools=yes, the domain=yes. :-) The concept is like ... inversion of inversion of control -- check for dependencies, then inject the dependent. It's a fresh look on an old problem. On this topic, looking forward, I'm interested in considering both dev and deployment environments as disposable appliances -- self-contained environments with no external dependencies. One important factor here is minimizing footprint -- not so much from a storage perspective, but because bandwidth (i.e., time) is an expensive UX resource. In the meantime, searching things like "Segmenting the LabVIEW Run-Time Engine" describes an unofficially-support method of solving current probs. Our root motivations are the same -- reduce pain introduced by shuffling around large dependencies. And even though IoIoC may not be optimal in many situations (especially in non-strictly controlled deployment targets), it is precipitously close to other solutions using some of the same tools. :-) Quote Link to comment
Mads Posted December 4, 2013 Report Share Posted December 4, 2013 Good idea. It is a bit sad that we have to resolve to such tricks though. In 2004 a typical installer from us would be about 4 MB. The same builds now take about 140 MB. I still use LabVIEW 7.1 every now and then if I need the small file size, and/or do not want an installer, but just have the RTE-files in the same folder as the executable. Same source code mostly, just older and more compact wrapping Quote Link to comment
hooovahh Posted December 4, 2013 Author Report Share Posted December 4, 2013 I still use LabVIEW 7.1 every now and then if I need the small file size, and/or do not want an installer, but just have the RTE-files in the same folder as the executable. Same source code mostly, just older and more compact wrapping Yeah I've used this technique. Newer versions of LabVIEW have issues with this but I have had some minor success in trying it. More research is needed. At some point it does get a little ridiculous trying to develop in 7.1 when you are used to modern features. And my modern I mean things like Listboxs with the properties and methods you are used to. And of course I'm familiar with the segmenting of the RTE. Very cool stuff I haven't got around to messing with it yet, but is another option for sure for a situation like the one I described. Quote Link to comment
Recommended Posts
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.