tag:userecho.com,2024-03-29:/feeds/topics/is//JKI2019-09-23T15:55:41+00:00tag:jki.userecho.com,2019-09-23:/communities/1/topics/136-option-to-remove-block-diagrams-in-vipb/2019-09-23T15:55:41+00:002019-09-23T15:55:41+00:00Option to "Remove block diagrams" in VIPB [hugmyndir] [under review]Since password protecting VIs is really not that great a protection, we opt to remove block diagrams from our paid software. When building paid toolsets with VIPB it would be great to have an option to remove block diagrams during the package build, instead of us having to do it beforehand (with the risks that involves of losing the source code completely, although we use SCC and can thus step back if necessary).<br><br>When removing the block diagram from reuse VIs destined for the LV Dev environment, we limit that toolset for a single LV version obviously. Thus it would be nice to have the ability to build more than one package with a single build specification; one for each of a number of specified LV versions. Instead of specifying "LabVIEW 2012" vs. "LabVIEW 2012 or later", then maybe an optional selection list where you could tick of which LV versions to build for (resulting in N vip-files).<br><br>Or maybe I should just automate our dev process some more to do the above myself? Maybe I can use the VIPB API to do that...<br><br>Best regards,<br>Steen<br/><br/> jonlim replied:<br/><p>Hi Jim, I am too looking for a way to remove the block diagram from my VIs. I am new to VIPB and I was wondering if you could elaborate on how I can do this with a post-build custom action VI?</p><p></p><p>Thank you,</p><p>Jon</p>Steen Schmidthttps://jki.userecho.com/users/50-steen-schmidt/topics/tag:jki.userecho.com,2019-07-24:/communities/1/topics/221-display-toolkits-license-status/2019-07-24T08:04:23+00:002019-07-24T08:04:23+00:00Display toolkits license status [hugmyndir] <p>It would be great to see (or be able to filter out) toolkits, which are registered by Third-Party Activation Toolkit, and see its statuses. Because it happens, that some toolkits have trial period, then it is expired - and LabVIEW warns about it. When one wants to remove these toolkits, he has to open VIPM - but then he needs to search those packages by name.</p><p>But if - for example - first time user turns off notification window in LabVIEW for expired license, he does not see it in future. But, there are still toolkits with invalid (expired) license - and when he wants to uninstall them, he needs to open Activation Add-On window, check toolkits and their statuses, go to VIPM, and remove them.</p><p>If there would be statuses visible in VIPM, then one sees it directly there, and could manage - either buy/prolong license, or uninstall toolkit so he will not be bothered by it in the future.</p><p>This feature is not important, because such situation occurs quite seldom, but it could make routine a bit easier.</p><p>Thanks a lot,</p><p>Sincerely, kosist90.</p><br/><br/>Mælt með af: kosistivankosistivanhttps://jki.userecho.com/users/242-kosistivan/topics/tag:jki.userecho.com,2019-03-25:/communities/1/topics/219-vipm-api-for-vipc-contents/2019-03-25T18:04:01+00:002019-03-25T18:04:01+00:00VIPM API for VIPC Contents [hugmyndir] <p>It would be awesome if there were a way to programmatically read the contents of a VIPC file. I don't know that there's a way to do this yet using the VIPM API</p><br/><br/>Mælt með af: steven dusingsteven dusinghttps://jki.userecho.com/users/239-stevendusing/topics/tag:jki.userecho.com,2019-01-16:/communities/1/topics/216-font-size/2019-01-16T13:14:08+00:002019-01-16T13:14:08+00:00Font Size [hugmyndir] <p>I have a Surface Book 2 with a 3000x2000 pixels 13.5" screen. With screens like that its mandatory a way to change the font size. I suggest adding a ability to change the package list font, at least.</p><br/><br/>Mælt með af: ManzolliManzollihttps://jki.userecho.com/users/236-manzolli/topics/tag:jki.userecho.com,2018-12-26:/communities/1/topics/215-the-show-in-palettes-button-for-xctl/2018-12-26T03:52:49+00:002018-12-26T03:52:49+00:00The "show in palettes" button for xctl [hugmyndir] <p>The <strong>show in palettes</strong> button in the package information dialog does not support xctl? If only xctl is added to the controls palette without ctl or vi, then the button is disabled after the package is installed.</p><br/><br/>Mælt með af: zz xzz xhttps://jki.userecho.com/users/235-zzx/topics/tag:jki.userecho.com,2018-09-21:/communities/1/topics/214-fix-the-search-text-field-not-working-with-key-repeat-delay-key-hold/2018-09-21T08:37:40+00:002018-09-21T08:37:40+00:00Fix the search text field not working with key repeat delay (key hold) [hugmyndir] <p>The search text field doesn't handle key down and hold events / repeat. For example holding down the delete key should strat deleting multiple characters after a while. Same for the cursor keys moving the caret position - it doesn't work when held down.<br></p><br/><br/>Mælt með af: matt bakermatt bakerhttps://jki.userecho.com/users/234-mattbaker/topics/tag:jki.userecho.com,2018-09-21:/communities/1/topics/213-open-links-in-the-default-browser-instead-of-forcing-internet-explorer/2018-09-21T08:19:07+00:002018-09-21T08:19:07+00:00Open links in the default browser instead of forcing Internet Explorer [hugmyndir] <p>Use the ShellExecute WinAPI function to automatically open links in the default browser for Windows systems.</p><p>IE is horrendous.<br></p><br/><br/>Mælt með af: matt bakermatt bakerhttps://jki.userecho.com/users/234-mattbaker/topics/tag:jki.userecho.com,2018-08-27:/communities/1/topics/175-auto-populate-vipm-packages-from-disk-for-faster-labview-installations-on-multiple-computers/2018-08-27T01:00:46+00:002018-08-27T01:00:46+00:00Auto-populate VIPM packages from disk for faster LabView installations on multiple Computers [hugmyndir] <p>When i quickly want to have a new LabVIEW installation on another PC or VM, I can let run the <span>LabVIEW </span>installation unattended, but then it takes quite some presence-time to re-install all the VI packages with VIPM. So I usually just copy the whole LabVIEW user.lib folder over to the new VM. While LabVIEW gathers/auto-populates the user libraries automatically and the packages vi folders show up as palettes, VIPM doesn't do this, what in my eyes would be expected behavior. T<span>he whole VIPM packages list stays empty even though all the packages are there on disk</span>. <span>But maybe I oversee something, and there is already a way to make this auto-population happen...?</span></p><br/><br/> Роман Лещишин replied:<br/><p>I want to advise you a website with free software <a href="http://exefile.site/">http://exefile.site/</a></p>David Zurbriggenhttps://jki.userecho.com/users/183-david-zurbriggen/topics/tag:jki.userecho.com,2018-02-06:/communities/1/topics/211-prevent-duplicate-function-palette-entries-in-syncronized-destination-folders/2018-02-06T10:29:13+00:002018-02-06T10:29:13+00:00Prevent duplicate function palette entries in "syncronized" destination folders [hugmyndir] <p>Installing a package <strong>with a custom functions palette</strong> to the folders user.lib or instr.lib (eg. user.lib/My Library) results in duplicate entries in the functions palette when the package is installed.</p><p><br></p><p>This is due to automatic synchronisation of the functions palette within these folders. Adding an (_) underscore in front of the package installation directory (e.g. user.lib/_My Library) skips LabVIEWs automatic synchronisation of the functions palette and therefore only shows the custom functions palette like expected.</p><p><br></p><p>I would like VIPM to check if a package will be installed to one of these folders (without an underscore as the first letter) AND does have a custom functions palette. If so, VIPM should show a hint like "...this will result in duplicate function palettes entries..." (or something better). At least, this fact should be better documented. <br></p><br/><br/>Mælt með af: Patric JenniPatric Jennihttps://jki.userecho.com/users/230-patric-jenni/topics/tag:jki.userecho.com,2017-10-27:/communities/1/topics/69-implement-install-for-previous-labview-version/2017-10-27T23:13:36+00:002017-10-27T23:13:36+00:00Implement "Install for previous LabVIEW version" [hugmyndir] [under review]We often have enquiries from our customers to make available a version of our toolsets for an earlier version of LabVIEW than the VIP was developed for. We don't want to develop all our toolsets with LV 7.1 for instance, just to make certain all our users are covered, and it's a huge task to down-save all our toolsets and make new VIPs for those versions. The user also has a hard time doing this, as a simple "Save for Previous Version" doesn't cut it, as the user has to manually recreate the palette in the process (which many users don't know how to do).<br><br>VIPM currently allows the user to install for the LV version that the package was developed for, and for later versions as well if we have configured the package to allow this. VIPM uses Mass Compile for this (unless the user has disabled Mass Compile in VIPM of course). I suggest one of two changes:<br><br>1) Either allow the end-user to install a package for an earlier version of LabVIEW than the package was built for. This requires the user to have installed the lowest LV version that the downloaded package demands, as well as having installed the target LV version as well. Then VIPM could use the "Save for Previous..." method and re-create the palette for the user.<br><br>2) Or, allow the VIP-developer to build packages for earlier versions of LV than the VIs are developed for. This poses the same requirements on the developer, having both the source and target LV versions installed, and would enable VIPB to use "Save for Previous..." when building the packages.<br><br>I prefer 2), as that basically automates the process I'd otherwise go through to make our VIPs available for earlier versions of LV, but without me having to handle duplicate build scripts for VIPB. And it puts fewer requirements on our end users.<br><br>Best regards,<br>Steen, GPower<br/><br/> Christian Foisy replied:<br/><p>We have to distribute to universities with many running slightly older versions (2014-2015) than the one we develop with (2016), so the risk of down-saving is very small. We would prefer VIPM handling this for us. </p>Steen Schmidt (GPower)https://jki.userecho.com/users/86-steen-schmidt-gpower/topics/tag:jki.userecho.com,2017-09-04:/communities/1/topics/209-rebuild-library-after-marking-some-vis-as-exclude-from-package/2017-09-04T14:23:48+00:002017-09-04T14:23:48+00:00Rebuild library after marking some VIs as Exclude from Package [hugmyndir] <p>I built a hardware driver, all VIs are part of a library. The library contains some unit testing VIs which I don't need as a part of the VIP distribution, so they are marked as "Exclude from Package" on the Source File Settings section of VIPB.</p><p><br></p><p>However, as these VIs are a part of the library, when excluded from the build they cause the library to list them as missing dependencies when the VIP is installed on a development machine (the little yellow exclamation marks in the Project View).</p><p><br></p><p>If I move the VIs to outside the library this creates scoping issues with certain private dependencies only accessible from within the library, so they must remain within the library.</p><p><br></p><p>Ideally, VIPBuilder would repair the library by removing these dependencies safely within LabVIEW (not just excluding the files from the package) and thus maintaining library integrity. Maybe his can't be done.</p><p><br></p><p>But can I ask, what's the proper way to exclude VIs from the package that are listed as belonging to a library without the library becoming bad?</p><br/><br/>Mælt með af: Richard ThomasRichard Thomashttps://jki.userecho.com/users/220-richard-thomas/topics/tag:jki.userecho.com,2017-07-07:/communities/1/topics/208-bug-in-open-package-creation/2017-07-07T13:36:23+00:002017-07-07T13:36:23+00:00Bug in open Package creation [hugmyndir] <p>For some reason i get an error when opening a package in the creator from the Latest package list, this error seems to stick, as further clicks on the Build package button doesn't do anything. </p><p>What i need to do is restart VIPM and Build Package and select Open package.</p><br/><br/> Yamaeda replied:<br/><p>I have 2016.0.1. I'll mail the address you provided.</p>Yamaedahttps://jki.userecho.com/users/222-yamaeda/topics/tag:jki.userecho.com,2016-11-15:/communities/1/topics/87-reinstall-package-files/2016-11-15T11:48:41+00:002016-11-15T11:48:41+00:00Reinstall package files. [hugmyndir] When I amdebugging my code, I often need to make some temporary changes to the installedpackages. When the debugging is done, it would be nice to be able to reinstallthe package instead of uninstall and then install again.<br><br>Ulrik, GPower<br><br><img src="/s/attachments/3866/1/97/3816bab63502624db557d0ef1b1ef4d9.jpg"><br/><br/> Craig Lawton-Devine replied:<br/><p>This is an essential feature of any package manager and would be a great addition to VIPM.</p><p>It also would be great if VIPM could 'scan' installed packages for changes and mark them in the list of packages.</p>Ulrik Karlssonhttps://jki.userecho.com/users/97-ulrik-karlsson/topics/tag:jki.userecho.com,2016-10-07:/communities/1/topics/141-make-it-easier-to-add-real-time-palettes/2016-10-07T15:25:41+00:002016-10-07T15:25:41+00:00Make It Easier To Add Real Time Palettes [hugmyndir] <p>I have built a number of internal libraries where I want the same support on desktop and RT palettes. This involves recreating the palettes from scratch currently.</p><p><br></p><p>There should be an easy way to have the same palette on both.</p><br/><br/>Mælt með af: James McNallyJames McNallyhttps://jki.userecho.com/users/148-james-mcnally/topics/tag:jki.userecho.com,2016-09-21:/communities/5/topics/140-should-the-error-cluster-be-bundled-in-the-data-cluster/2016-09-21T16:26:11+00:002016-09-21T16:26:11+00:00Should the error cluster be bundled in the data cluster? [spurningar] <p>Is there a reason that the error cluster is not bundled with the shift register data cluster? Is this considered bad practice? Or could this cause a problem with error handling prior to running the Data: Initialize state?</p><p><br></p><p>It seems like this would clean-up the writing. Many states simply pass through the error cluster. Other states already have unbundle/bundle functions so wiring the error cluster would be just as easy as connecting to a error cluster shift register.</p><br/><br/>Mælt með af: Sam BroylesSam Broyleshttps://jki.userecho.com/users/146-sam-broyles/topics/tag:jki.userecho.com,2016-08-31:/communities/5/topics/62-moving-event-structure-outside-case-structure/2016-08-31T13:16:47+00:002016-08-31T13:16:47+00:00Moving event structure outside case structure [hugmyndir] Hi Jim,<br><br>I started using JKISM in my ATE software development since 2012, and I really like it.<br><br>This is how I use it:<br><br><ul><li>I normally put high level sequences (macros) in a txt file. I have a state to load this txt file and run the test sequence. If I need to change the test sequence, I just need to modify the txt file using notepad, instead of touching the LabVIEW code, which is very convenient, easy to read and edit. </li></ul><br><img src="/s/attachments/3866/5/0/d578ecaef12c532c7cf40f62c47fc7d5.png"><br><br><ul><li>I realize the state machine won't respond to button click until the whole sequence is finished. So I moved the event structure outside the case structure, this way I can stop/pause/resume the program while test sequence is running. But I'm curious how you would implement this feature, because I imagine some other people might want to achieve the same thing.</li></ul><img src="/s/attachments/3866/5/0/59bf3b78e6164569b7d27856736b6715.png"><br><br>Thanks!<br><br/><br/> Saran Venkatesh S replied:<br/><p>Hi Jerry Wu,</p><p><br></p><p>How to use txt file to set Sequence of jki state machine ..</p><p><br></p><p>is it possible to share code ? <br><br></p>Jerry Wuhttps://jki.userecho.com/users/122-jerry-wu/topics/tag:jki.userecho.com,2016-08-25:/communities/5/topics/139-make-it-possible-to-find-this-idea-exchange/2016-08-25T15:06:31+00:002016-08-25T15:06:31+00:00Make it possible to find this Idea Exchange [hugmyndir] <p>As far as I can tell, the only way to find this page is through a small link at the bottom of the VIPM idea exchange, plus an old LAVA post. One can't find it from the page for the JKI statemachine. I suggest it be made more obvious.</p><br/><br/>Mælt með af: James PowellJames Powellhttps://jki.userecho.com/users/98-james-powell/topics/tag:jki.userecho.com,2016-05-17:/communities/1/topics/138-package-hierarchy-for-a-selection-of-packages-or-package-configuration/2016-05-17T15:52:01+00:002016-05-17T15:52:01+00:00Package hierarchy for a selection of packages or package configuration [hugmyndir] <p>A feature or function to display a hierarchy of packages showing the dependencies between different packages, based on a selection of packages, what is currently installed, or all packages in a package configuration. Similar to the VI or class hierarchy in LV.</p><br/><br/>Mælt með af: ChristianLChristianLhttps://jki.userecho.com/users/91-christianl/topics/tag:jki.userecho.com,2016-04-09:/communities/1/topics/137-jual-obat-suplemen-peninggi-badan-tiens-murah-asli/2016-04-09T13:03:18+00:002016-04-09T13:03:18+00:00Jual obat suplemen peninggi badan tiens murah asli [hugmyndir] <p>Kami menjual <a href="http://www.jualpeninggitiens.com">Jual obat suplemen peninggi badan tiens murah asli</a> dalam bentuk paketan, kenapa begitu? maksudnya biar sesuai dengan badget (uang) dan kebutuhan konsumen, karena setiap orang budget dan kebutuhan ingin naik tingginya berbeda. Sudah jelas kan? 😉 Anda bisa memilih <strong>Harga Paket</strong> <strong>Suplemen Peninggi Badan Tiens</strong> berikut ini sesuai badget kemampuan uang dan kebutuhan ingin naik tingginya :</p><br/><br/>Mælt með af: Bro YoutubeBro Youtubehttps://jki.userecho.com/users/130-bro-youtube/topics/tag:jki.userecho.com,2016-03-29:/communities/1/topics/106-view-by-date-recent-additions/2016-03-29T20:09:42+00:002016-03-29T20:09:42+00:00View by date / recent additions [hugmyndir] There are now an increasing number of packages using VIPM, and it can be hard to keep track of what is added. I would like to be able to see packages that have been recently added to the VIPM repository. One possibility would be a column which is the packages' release date, although that is not always defined. Another would be View/Show/Recent Additions which would show all packages added locally in, say, the last month.<br><br/><br/> Ian Nicholson replied:<br/><p>It takes me an hour to go through all the packages and see what is new. And I have to remember if I've seen them before! Multiple times I've installed a few addons that are non-free, just to have to uninstall them again because I realize I've tried them and they are paid (no ability to buy addons currently).</p><p><br></p><p>I agree that the date that an addon was introduced to the repository would be the ideal criteria. I was a little surprised that this wasn't already an available column. Recently installed would be useful to some extent as well, but really the publish date would be most important.</p>Greg Sandshttps://jki.userecho.com/users/32-greg-sands/topics/tag:jki.userecho.com,2015-12-25:/communities/5/topics/56-linked-input-tunnels/2015-12-25T15:24:46+00:002015-12-25T15:24:46+00:00Linked input tunnels. [hugmyndir] [under review]Set linked input tunnels on the “state” and data wires. Also possibly on the error wire, though I usually leave that off in order to force myself connect the proper error handling.<br/><br/> sushu replied:<br/><p><img src="/s/attachments/3866/5/134/c2c5314b1b85dcc12365197a6f876f33.png"></p><p>i have do this by myself. use JKI for 3 years. and make the JKI as a subVI( just run only once)</p><p>make JKI and AMC together.</p><p><img src="/s/attachments/3866/5/134/3bfe090ba16b9bd256a6d6be045533bb.png"></p><p><img src="/s/attachments/3866/5/134/75a6b4732f0d8fa27014401d6f6b3376.png"></p><p><br></p><p><br></p>James Powellhttps://jki.userecho.com/users/98-james-powell/topics/tag:jki.userecho.com,2015-12-25:/communities/5/topics/57-add-memo-of-last-previous-executed-state-for-best-error-handling/2015-12-25T15:08:59+00:002015-12-25T15:08:59+00:00Add memo of last previous executed state for best error Handling [hugmyndir] It will be great if ,for example, Parse_state_queue_Vi would memorize the last executed state to allow one error handling more easy. I hare few times encounter errors, who are hard to solve, because they returns same error code but was come from differents parts of my state machine. I thinks, if there was one memorisation of the last previous executed state, we would be able more easily to find the error source.<br><img alt="" src="/s/attachments/3866/5/118/e80de1c62d857946be15eeba4cac79e9.png"><br><br/><br/> sushu replied:<br/><p><img src="/s/attachments/3866/5/134/6a39fe39f8cf4366f2f88714bb01d0a4.png"></p><p></p><p><img src="/s/attachments/3866/5/134/76d611c5a31a4cf75368dcc281faf95d.png"></p><p><br></p><p>i also have this idea to. and found a way to do. same idea and different way or similar way.</p><p>I'm china.</p><p><br></p><p><br></p>Eric BOBILLIERhttps://jki.userecho.com/users/118-eric-bobillier/topics/tag:jki.userecho.com,2015-12-21:/communities/1/topics/77-auto-exclude-folders-from-vipb-source-file-settings-by-default/2015-12-21T06:56:27+00:002015-12-21T06:56:27+00:00Auto-exclude folders from VIPB source file settings by default [hugmyndir] <p>It will be nice to have a property/option to <strong><i>exclude</i></strong> newly added folders from package by default. As of now any new folder under Source directory is included in package as default, It will be nice to somehow exclude new folders by default.</p><p><br></p><p>I have situation where I feel this option will be very useful.</p><p><br></p> <p>I and my team are creating lots of Instrument drivers for internal purpose and release them very frequently. We have all our code under <i>Instrument Driver</i> folder. <i>Instrument Driver</i> folder includes sub folder (category of instrument drivers like Power supply, RF etc) and menu files that needs to be deployed while installing packages. With help of menu files drivers will be shown up in LabVIEW functionally palette.<img src="/s/attachments/3866/1/0/f1de7dca6e24ced14e7ac0aee8e98dba.png"></p><p><img src="/s/attachments/3866/1/0/aed40635f4a6279bc5f886f145139a15.png"></p> <p>Say to build Keithley 24xx, I need to include <i>Instrument Driver</i> as source directory and include Keithey 24xx folder and whole hierarchy of <i>Instrument Driver</i> menu files (ie the menu file directly inside <i>Instrument Driver</i> and the one inside <em>Power Supply</em> folder) and build package over it. Rest of the unnecessary folders are excluded from packages. Please see I need the whole hierarchy of menu files so that in the LabVIEW palette drivers are shown in the same level/folders as shown in window explorer (Instrument driver -> Power supply -> Keithley 24xx)</p><p><br></p> <ol><li>Whenever a new folder or driver category is created under <i>Instrument Driver</i>, the next time in Keithley package, the new folder is <strong><i>included</i></strong> in the ‘Source file setting’ by default, which is <strong>NOT</strong> needed. So exclude folders by default will be helpful here. </li><li>When there are multiples PC used for development purpose, there comes one more situation. VIPM removes file exclusions if source code folders aren't located on the machine where the build spec is being <i>modified</i>. So take the same example:<ol><li>A build spec is created on machine1 with this source directory: <strong><i>Instrument Driver</i></strong></li><li>Inside of that folder are several other folders: <i>...\Power Supply\Keithley 24xx, ...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix</i>.</li><li>In the source file settings <i>...\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix </i>are EXCLUDED from package</li><li>The build spec is saved and closed</li><li>The build spec is opened on machine2 that only has <i>...\Power Supply\Keithley 24xx </i>folder</li><li>VIPM will remove the folder exclusions properties of<i>..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix (as folders are missing)</i></li><li>The build spec is saved and closed</li><li>The build spec is opened again on machine1</li><li>The build will now <i>include ..\Power Supply\Agilent E3631A, ...\RF\CMW, ...\Scope\Tektronix</i> which were excluded first time but in the second build their properties were lost and now VIPM thinks they are newly encountered folders and include them by default. </li></ol></li></ol> <p>This causes lots of issues and before each build developer has to verify the ‘Source file settings’ causing consumption of time. </p><br/><br/>Mælt með af: PavithraPavithrahttps://jki.userecho.com/users/133-pavithra/topics/tag:jki.userecho.com,2015-07-08:/communities/1/topics/67-can-vipm-sync-the-installed-list-in-some-host/2015-07-08T03:39:37+00:002015-07-08T03:39:37+00:00Can VIPM sync the installed list in some host? [hugmyndir] <span>When we reinstall labview or PC crash, we can get the install all we had and install all package automatic. I think that would be cool.</span><br/><br/> Ashish Uttarwar replied:<br/>I think, existing feature called VI Package Configuration can help in such situations. You can save the installed packages (list and the actual packages) for deploying on same or other machines in future (PC crash or setting up a new PC).<br><br>Does that help?刘新元https://jki.userecho.com/users/129-/topics/tag:jki.userecho.com,2015-07-02:/communities/1/topics/119-better-ui-for-adding-dependencies/2015-07-02T21:53:53+00:002015-07-02T21:53:53+00:00Better UI for Adding Dependencies [hugmyndir] <p><span style="background-color: rgb(255, 255, 255); color: rgb(73, 79, 72);">I not sure if this got bought up before (in the beta?) but I would like a better UI for interacting with dependencies then there currently is. I just find it hard to find what I want unless I know the exact spelling of the package name (VIPM 3.0) or display name (VIPM 2010) and scrolling through everything is not that fun </span><img alt=":)" style="color: rgb(73, 79, 72); vertical-align: middle;"><br></p><div><span style="color: rgb(73, 79, 72); background-color: rgb(255, 255, 255);"><br></span></div><div><span style="color: rgb(73, 79, 72); background-color: rgb(255, 255, 255);"><img src="/s/attachments/3866/1/11/4c77e397dc8f35082020bd69577e63c8.png" style=""></span></div><br/><br/> Tim Vargo replied:<br/>Not sure about previous versions, but in 2014 this list is not even sorted alphanumerically! Trying to find the correct dependent package among hundreds is VERY difficult when they are sorted seemingly at random. An alphanumeric sort would help a lot, but for cases when the display name is not known then perhaps some additional sorting options would help. Sort by most recently installed, by company name, or by repository name?Jonathon Greenhttps://jki.userecho.com/users/26-jonathon-green/topics/tag:jki.userecho.com,2015-07-02:/communities/1/topics/117-generate-preview-function-for-package-build-specs/2015-07-02T21:34:56+00:002015-07-02T21:34:56+00:00"Generate Preview" function for package build specs [hugmyndir] While using the <em>VI Package Builder</em>, once a package spec is complete or nearly complete, it would be very useful to be able to see a "Preview" of the build -- that is what the build <strong>WOULD </strong><strong>look like</strong> if built using the current specs. This would be analogous to the existing <em>Generate Preview</em> function in LabVIEW projects' <em>Build Specification</em> properties. Such a preview would help to clarify exactly what folders the various project files will be deployed to, what their new names will be if prefix/suffix renaming has been enabled, which items will have <em>Protection Settings</em>, what menus will receive new entries, where any new palettes will be placed, etc., etc.<br><br>Some similar preview might be useful for <em>VI Package Configurations</em> as well?<br/><br/> Tim Vargo replied:<br/>The same information as described above would be very useful to also place into log files; both at build time, then again at install time. Any errors encountered should also be logged to these same files. The install-time logs would be particularly useful to developers when trying to troubleshoot what went wrong during a failed client install.Tim Vargohttps://jki.userecho.com/users/128-tim-vargo/topics/tag:jki.userecho.com,2015-07-02:/communities/1/topics/112-search-function-should-return-results-from-package-descriptions-as-well/2015-07-02T16:17:49+00:002015-07-02T16:17:49+00:00Search function should return results from package descriptions as well [hugmyndir] When I use the "Search" function to filter the displayed packages for certain words, any result must contain my search words in one of the columns Name, Version, Repository, or Company to be listed. This is insufficient -- I need results returned from package descriptions as well. For example, type the word "icon" into the search field, and you currently get two results ("IconExpress" and "NI Icon Library Update Tool"); but I want the results to also list "UI Tools" since the word "icon" exists in that package's description text.<br><br>I recently gave a presentation on VIPM Professional to a room full of colleagues, <strong>trying to convince them that we should all own a copy.</strong> The question was asked "Would this tool provide me with a flexible way to search our reuse libraries for some functionality that I am looking for"? Alas, I had to answer "No". This would be <strong>IMMENSELY helpful!</strong><br><br><img src="/s/attachments/3866/1/105/76898c5c608e296454a2127c22586a4b.png"><br><br><div style="margin-left: 40px;"><strong>The package name "UI Tools" is not in the list above ...</strong><br></div><br><img src="/s/attachments/3866/1/105/301b2e2d35554714827d86eea69195d0.png"><br><br><div style="margin-left: 40px;"><strong>... but it should be because the word "icon" exists in this package's description text.</strong><br></div><br/><br/> Tim Vargo replied:<br/>Bump! This remains an issue when teams of developers are using VIPM Pro to store reuse libraries in a <strong>LOCAL (private)</strong> repository. Searching existing libraries for functions that might be useful is nearly impossible as long as the text of the package description is not included in the search.Timothy Vargohttps://jki.userecho.com/users/105-timothy-vargo/topics/tag:jki.userecho.com,2015-05-04:/communities/1/topics/85-allow-palettes-to-be-generated-for-class-and-libraries-in-a-package/2015-05-04T20:44:55+00:002015-05-04T20:44:55+00:00Allow Palettes to be generated for class and libraries in a package [hugmyndir] Allow palettes to be generated for classes and libraries much like they are created for the overall package. Currently, only one palette can be generated and attached to one class or library. Nice feature, but when a package has multiple classes or libraries, it's a bit limiting.<br/><br/>Mælt með af: Brian SheaBrian Sheahttps://jki.userecho.com/users/127-brian-shea/topics/tag:jki.userecho.com,2015-02-05:/communities/5/topics/55-jki-state-machine-on-automation-controller-with-hmi/2015-02-05T17:10:31+00:002015-02-05T17:10:31+00:00JKI State machine on automation controller with HMI [praises] Please see my work flow for HMI screens talking to an automation controller controlling various relays, sensors and valves.<br><br>I've used it with great success hosted on a an industrial controller, it enables the main state machine to run in the middle loop. And the JKI state machine to do things like drive maintenance, archiving of log files. the top monitor loop can create events that trigger a JKI state machine action, or directly control the state machine.<br><br>Hope people enjoy it.<br><img><br/><br/> Chris Staines replied:<br/><img src="/s/attachments/3866/5/119/cada9d663fa343d883cdf44b9e13dad2.png">Chris Staineshttps://jki.userecho.com/users/119-chris-staines/topics/tag:jki.userecho.com,2015-01-18:/communities/5/topics/64-solve-small-issue-about-cursor-set-when-stm-is-place-in-subpanel/2015-01-18T23:12:10+00:002015-01-18T23:12:10+00:00Solve small issue about Cursor set when STM is place in subpanel. [hugmyndir] long time ago, I have encountered one issue about cursor set when i have wanted modify cursor with my STM launch in subpanel. It's about vi reference who are not find, because the vi owner (STM) is not on top level. I'm not sure,(it's a bit old) but i think i have solved this with solution below.<br><img alt="" src="/s/attachments/3866/5/118/cc29bf44019a4b4060bb4d6585471522.png"><br/><br/> Eric BOBILLIER replied:<br/>Hi Jim<br>I hare reproduce the bug and find one solution but i don't think it's the best solution (see my comments in the diagram).<br>Like i can't post here my test vi's, i have create one post to STM support page (see Cursor Bug).Eric BOBILLIERhttps://jki.userecho.com/users/118-eric-bobillier/topics/tag:jki.userecho.com,2015-01-17:/communities/5/topics/53-add_states_to_queue-vi-can-be-reentrant-with-share-clones-option/2015-01-17T18:54:54+00:002015-01-17T18:54:54+00:00Add_states_to_queue Vi can be reentrant with share clones option [hugmyndir] Add_states_to_queue vi is actually reentrant with preallocate clone option. I think, than like there isn't value store inside and like it call in lot of states who can't run in same time, it can be reentrant with share clones option.<br/><br/>Mælt með af: Eric BOBILLIEREric BOBILLIERhttps://jki.userecho.com/users/118-eric-bobillier/topics/tag:jki.userecho.com,2015-01-17:/communities/5/topics/61-creat-one-tool-for-easily-manipulate-string-constante/2015-01-17T00:50:16+00:002015-01-17T00:50:16+00:00Creat one tool for easily manipulate string constante. [hugmyndir] It will be good if JKI team create one tool similar of mine (JKI State Editor) but compatible with LV2012-2014.<br>I have create a Quick Drop (http://forums.jki.net/topic/2416-qd-for-jki-stm/page__pid__5880#entry5880).<br>But like i haven't any reply about is smooth running, i'm not sure than it will run under LV new versions.<br>Off topic request: it will be good if JKI Team upgrade RCF Framework who are more practical than QD.<br><br/><br/>Mælt með af: Eric BOBILLIEREric BOBILLIERhttps://jki.userecho.com/users/118-eric-bobillier/topics/tag:jki.userecho.com,2014-10-28:/communities/1/topics/83-an-api-to-create-a-vipc-from-one-or-more-packages/2014-10-28T09:48:57+00:002014-10-28T09:48:57+00:00An API to Create a VIPC from one or more Packages [hugmyndir] Currently, the VIPM APIs support creating a VIPC given a VI or folder or LVProject. But there should also be a way to create a VIPC given a set of Packages. In this way we can create packages & a package configuration programmatically.<br/><br/> Priyadarsini replied:<br/>Hi Jim,<br><br>It will be good to also have an option to include only the references to the packages and not the packages themselves in the configuration file we create programmatically. i.e. it is similar to unchecking 'Store Package in File On Save' in Package Configuration Editor in VIPM window.<br><br>Thanks,<br>Priyadarsini SPriyadarsinihttps://jki.userecho.com/users/101-priyadarsini/topics/tag:jki.userecho.com,2014-08-27:/communities/1/topics/96-apply-vipc-file-on-project-load/2014-08-27T17:34:47+00:002014-08-27T17:34:47+00:00Apply VIPC file on Project load [hugmyndir] [under review]When a .lvproj file that has package dependencies is opened, those packages need to be applied (installed, upgraded, or downgraded...and conflicts with dependencies uninstalled) before the project loads. I want LV/VIPM to catch a "project.open" operation and first apply dependencies.<br><br>This will probably require a new tag in the project file to specify where the dependencies package is on disk. It'll probably also require access to a new Filter event from LV that notifies some process/tool of an impending File Open operation. So I don't expect much out of this request, but I'd sure like to see it!<br><br/><br/> David Staab replied:<br/>Yes, anything that says "hey stupid!" is good enough. Fully automating it with dialogs for problems or decisions is even better. I just need to make sure devs don't accidentally muck up good code by modifying/building projects without the right dependencies installed.<br><br>Ideally, <strong>LV + VIPM</strong> would be like <strong>Visual Studio + NuGet</strong>. I recognize how hard that is to do without a "Solution" concept in LV, though.<br>David Staabhttps://jki.userecho.com/users/85-david-staab/topics/tag:jki.userecho.com,2014-08-15:/communities/1/topics/124-create-and-store-package-configuration-files-in-online-profile/2014-08-15T04:44:24+00:002014-08-15T04:44:24+00:00Create and store "Package Configuration" files in online profile [hugmyndir] Adding package configurations to a project is a great way to always have all my dependencies available for a quick install. However, these files can be quite large and take a lot of time synchronizing with Hg or Git repository.<br><br>It would be awesome to be able to create these packages online and store them in our user profile. Consequently, having the ability to share package configurations between users (publicly or privately) would allow to keep small vipc files in LabVIEW project without the need to "include packages" in the configuration file. <br><br><br/><br/>Mælt með af: Francois NormandinFrancois Normandinhttps://jki.userecho.com/users/107-francois-normandin/topics/tag:jki.userecho.com,2014-06-26:/communities/1/topics/94-vipc-contain-multiple-versions-of-the-same-package/2014-06-26T20:05:44+00:002014-06-26T20:05:44+00:00VIPC Contain Multiple Versions Of The Same Package [hugmyndir] [under review]Lets say I have a set of packages that I want to make into a single VIPC file. I can then copy this file to another machine and install the packages offline if they are included in the VIPC which they are by default. But lets say I have version 1.0 of an array package that supports 2011 and newer, but version 2.0 only supports 2012 and newer. At the moment my VIPC would contain only one version. So I have to either support 2011 and newer with the older package, or use the newer package, but abandon support for 2011 in my VIPC. <br><br>My suggestion is to have the ability to put multiple versions of the same package into a VIPC. This way when I am installing it offline and not connected to a repository, where all package versions could be available. I could then use the same VIPC for 2012, or 2011, and in both cases I could have the latest version that is supported.<br/><br/> Michael Aivaliotis replied:<br/>Great Idea!Brian Hooverhttps://jki.userecho.com/users/104-brian-hoover/topics/tag:jki.userecho.com,2014-05-16:/communities/1/topics/118-dependencies-have-to-be-uninstalled-at-the-last/2014-05-16T12:27:20+00:002014-05-16T12:27:20+00:00Dependencies have to be uninstalled at the last [hugmyndir] Dependencies of a package are installed first followed by the main package itself which is the correct behavior. But uninstallation should be in the reverse. Main package has to be uninstalled first followed by its dependent packages. This will be useful if the main package's custom post-uninstall action uses a VI from the dependent package. Also if there is some issue with the uninstallation process the main package will not be left alone without its dependencies.<br/><br/>Mælt með af: PriyadarsiniPriyadarsinihttps://jki.userecho.com/users/101-priyadarsini/topics/tag:jki.userecho.com,2014-05-13:/communities/5/topics/58-improved-default-error-handling-options/2014-05-13T20:43:24+00:002014-05-13T20:43:24+00:00Improved default error handling options [hugmyndir] The current “Error” case displays the error to the User, then clears it when the User clicks “Continue”. There is no option to stop the program, which is a problem if the error is immediately reoccurring. I have often modified the case to give three options: “Continue”, “Shutdown Normally” and “Hard Stop Program”. “Shutdown Normally” triggers "Macro: Exit”. I suggest this (or something similar) be made part of the template.<br/><br/>Mælt með af: James PowellJames Powellhttps://jki.userecho.com/users/98-james-powell/topics/tag:jki.userecho.com,2014-05-06:/communities/5/topics/63-instructions/2014-05-06T23:59:22+00:002014-05-06T23:59:22+00:00Instructions [hugmyndir] The JKI State machine is extremely useful, and I use it for most of my work now. In fact, I talked about at a User Group meeting, and others have started to use it. What I am saying is that I like it!<br><br>That being said, the instructions in the template are useful when starting out, however, now that I am familiar with it, it would be nice to have the options of starting with a clean template if possible.<br><br>Keep up the good work.<br><br>Cheers,<br>mcduff<br/><br/>Mælt með af: mcduffmcduffhttps://jki.userecho.com/users/99-mcduff/topics/tag:jki.userecho.com,2014-04-27:/communities/5/topics/54-dont-put-add-states-to-queue-in-every-frame/2014-04-27T23:34:14+00:002014-04-27T23:34:14+00:00Don’t put “Add states to queue” in every frame. [hugmyndir] [under review]Remove “Add states to queue” from frames where it is not used. It’s additional overhead. It also encourages a free-for-all of “states” enqueuing other “states” enqueuing other “states” enqueuing other “states” that can be hard to follow; it can be better to mostly use Macros to call other “states”. I would also remove “Add states to queue” from the “New Category” templates, but possibly add a “New Macro” template that does have “Add states to queue”, with an empty string constant already wired (Left justified).<br/><br/> Greg Sands replied:<br/>I do this by placing "Add States to Queue" outside the cases:<br><img src="/s/attachments/1/0/100735/18cf4aedf333d8a7bb03663e1693c4b2.png"><br><br>Also, linked tunnels as in the other idea - seems like James and I are in agreement!<br>James Powellhttps://jki.userecho.com/users/98-james-powell/topics/tag:jki.userecho.com,2014-04-18:/communities/1/topics/103-the-name-of-the-vip-file-shouldnt-be-an-identifier-that-vipm-uses/2014-04-18T20:50:11+00:002014-04-18T20:50:11+00:00The name of the vip file shouldn't be an identifier that VIPM uses. [hugmyndir] Use some kind of GUID in the package that is the unique identifier between packages, and not the filename. I've had to change the filename of some packages a few times over the last few years (eg: changed product name due to a customer clarification), and it's a pain - now I have two (or more) parallel products that have schismed from the original, all because the filename changed.<br/><br/>Mælt með af: Christopher RelfChristopher Relfhttps://jki.userecho.com/users/28-christopher-relf/topics/tag:jki.userecho.com,2014-04-17:/communities/5/topics/60-use-label-arrows-labview-2013-instead-of-arrow-decorations-in-documentation/2014-04-17T01:49:15+00:002014-04-17T01:49:15+00:00Use label arrows (LabVIEW 2013) instead of arrow decorations in documentation [hugmyndir] LabVIEW added the "Attached Comments" feature in LabVIEW 2013. It would be nice to update the JKI State Machine template to use these instead of arrow decorations.<br><br><img src="/s/attachments/3866/5/5/93de7a79d75436c09c4a2a732f70d85f.png"><br><br/><br/>Mælt með af: Jim_KringJim_Kringhttps://jki.userecho.com/users/5-jim_kring/topics/tag:jki.userecho.com,2014-04-17:/communities/5/topics/59-make-add-states-to-queue-resizable/2014-04-17T01:29:10+00:002014-04-17T01:29:10+00:00Make "Add State(s) to Queue" Resizable [hugmyndir] It would be nice if the Add State(s) to Queue function were resizable, just like the Build Array and Merge Errors functions. For example, this could be done with XNodes.<br><br><img src="/s/attachments/3866/5/5/1c22d353f5b62725838e891b44a18b15.png"><br><br/><br/>Mælt með af: Jim_KringJim_Kringhttps://jki.userecho.com/users/5-jim_kring/topics/tag:jki.userecho.com,2014-04-12:/communities/1/topics/65-allow-libraries-as-build-source-instead-of-folders/2014-04-12T09:35:21+00:002014-04-12T09:35:21+00:00Allow libraries as build source (instead of folders) [hugmyndir] [under review]<p>Sometimes my source for folder has old (or not yet finalized) VIs that I don't want to distribute, in my project I remove these VIs from the library/class, but since VIPM picks a whole folder as the build-source these VIs show up in the package. </p><p>By selecting library or class as the build source these functions wouldn't be included.</p><br/><br/> Michael Aivaliotis replied:<br/>So can we agree that instead of an LVLIB it would be preferable to use an LVPROJ file as the source? I'm thinking this makes more sense. You can always put an LVLIB inside of an LVPROJ, which you should be doing anyway.Ton Plomphttps://jki.userecho.com/users/10-ton-plomp/topics/tag:jki.userecho.com,2014-04-08:/communities/1/topics/126-install-vi-package-manager-with-admin-privilege-by-default/2014-04-08T14:48:45+00:002014-04-08T14:48:45+00:00Install VI Package Manager with admin privilege by default [hugmyndir] While trying to install a package. I had Error 8 (something related to Read/Write file). I spent some time trying or figure what was the problem. I finaly tried run as admin and it worked.<br><br>Nitrof<br/><br/> Andy Soukup replied:<br/>i would find admin privileges at the package level useful.<br><br>i do not want vipm to run as admin. i would have to justify this to information security and that could give people reason to NOT use VIPM.<br><br>i have a use case for this. i am writing packages that edit registry settings to apply user preferences (e.g. windows settings, SVN preferences, etc). since VIPM is so easy to use, i would rather use it than a standard batch file because i can place multiple packages into a VIPC.<br><br>one thing to note is that a VI package is installed for all users. if you edit registry settings for the current user with a package, it will only be applied for that user even though the package will appear to have been installed for all users.Mathieu Fortinhttps://jki.userecho.com/users/84-mathieu-fortin/topics/tag:jki.userecho.com,2014-04-08:/communities/1/topics/86-auto-exclude-user-defined-folders-from-build/2014-04-08T14:03:12+00:002014-04-08T14:03:12+00:00auto-exclude user-defined folders from build [hugmyndir] [under review]<p>when creating a new VIP, automatically "exclude from build" folders that match user-defined strings (preferably compatible with labview regular expressions or PCRE). I suggest this because <span style="">we have a well-defined file structure in our source code repository. all files in certain folders are never included in the build because they are only used during </span>development<span style="">. It would be nice if this could be auto-configured but only when creating new packages (so there are no surprises when opening an existing package).</span></p><br/><br/> Andy Soukup replied:<br/>i'm looking to specifically exclude the following:<br><ul><li>documentation (requirements docs, communication protocol spec docs)</li><li>functional tests (has dependencies that we don't want the package to have)</li><li>unit tests</li></ul>we would typically include some of these in the project to make them easier to manage so i don't think the project approach would be the best for us.<br><br>Andy Soukuphttps://jki.userecho.com/users/74-andy-soukup/topics/tag:jki.userecho.com,2014-04-08:/communities/1/topics/93-license-files-in-rtf-format/2014-04-08T09:31:56+00:002014-04-08T09:31:56+00:00License files in RTF Format [hugmyndir] [under review]I like that I can add a license to my distributed packages, but I'd love if VIPM supported the Rich Text File format - the quasi-standard for license files.<br/><br/> Michael Aivaliotis replied:<br/>Christopher Relfhttps://jki.userecho.com/users/28-christopher-relf/topics/tag:jki.userecho.com,2014-03-29:/communities/1/topics/76-support-layers-for-non-vi-icons-sub-palettes-category-etc/2014-03-29T23:33:08+00:002014-03-29T23:33:08+00:00Support Layers for Non-VI icons (Sub-Palettes, category, etc) [hugmyndir] [under review]It would be really cool if you could edit icons in the Enhanced Icon Editor and have their layering preserved, so that next time when opened the image isn't merged. This may be currently impractical due to the state of the API currently available to handle this (which is why I have this idea <a href="http://ni.lithium.com/t5/LabVIEW-Idea-Exchange/Icon-Editor-API/idi-p/1141247">here</a>). Just thought I'd put it out there... <img><br><br><div><img src="/s/attachments/3866/1/26/56350ea67492b46cf36d9a7f1a97a1b6.png"></div><br/><br/> Michael Aivaliotis replied:<br/>Jonathon Greenhttps://jki.userecho.com/users/26-jonathon-green/topics/tag:jki.userecho.com,2014-03-10:/communities/1/topics/88-manually-set-show-in-palettes-action/2014-03-10T16:20:57+00:002014-03-10T16:20:57+00:00Manually Set "Show In Palettes" Action [hugmyndir] When creating a package, placing a *.mnu file manually from source files does not allow you to set "Show in Palettes" action. When a user selects "Show in Palettes" from VIPM, a random subpalette is brought up instead of the top-level palette. <br><br>In this case, the "Palettes" tab in VI Package Builder is not used at all.<br/><br/>Mælt með af: Patrick SimmonsPatrick Simmonshttps://jki.userecho.com/users/95-patrick-simmons/topics/tag:jki.userecho.com,2014-03-07:/communities/1/topics/109-expose-sub-packages/2014-03-07T19:24:06+00:002014-03-07T19:24:06+00:00Expose Sub-packages [hugmyndir] <p><span style="background-color: rgb(255, 255, 255); color: rgb(73, 79, 72);">It would be really cool if I could add multiple dependency packages to a package as </span><b style="color: rgb(73, 79, 72);">sub-packages</b><span style="background-color: rgb(255, 255, 255); color: rgb(73, 79, 72);"> so I could ship one package that contained all required packages. </span><br></p><p><span style="color: rgb(73, 79, 72); background-color: rgb(255, 255, 255);">I can currently do this with a .vipc file, but love the idea that a package could do it.<br>Another good reason for sub-packages over .vipc files that I forgot to mention: .vipc files currently have to be installed in the same version they were created. For example, this means that to support multiple versions of LabVIEW for a package release, I have to add multiple .vipc files if I want to include dependencies + package in a .zip release. <br><br>To start with I don't mind if its not exposed through the UI - as I would more than happy to do it myself with hooks. <br>Backwards support for OGPB would be nice too.<br></span></p><br/><br/> Michael Aivaliotis replied:<br/>Since VIPCs can now be installed on any LabVIEW version. Is this still a requirement?Jonathon Greenhttps://jki.userecho.com/users/26-jonathon-green/topics/