Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hi, Where are you getting stuck? What's the last action that you are taking? What are you seeing and what did you expect to happen? When I select File>>Add Package(s), I see the following dialog: When you select packages and press Add, they should appear in your package list. If you don't see anything, make sure that you have selected a LabVIEW version selected: If no LabVIEW versions are available, make sure that you've configured your LabVIEW versions in the Options dialog. Let me know if this helps or if you still have questions. Thanks, -Jim
  2. Hi Daklu, You've identified a couple great use cases: 1) select a list of packages and then review each of their details 2) browse the package details and add them to a list of VIs "to be installed" (almost like an installation "shopping cart") You're right that it might work well to make the Package Information dialog non-modal to make it easier to browse packages. One trick that you can use to reduce the number of mouse clicks is to use the Escape key to close the Package Info dialog (rather than using your mouse to press the Close Window or Done buttons). Another way we might (some day) be able to achieve use case #1 is to allow you to select several packages and then select Package>>Get Info from the menubar (or right-click on the package and choose Get Info). Currently, the Get Info menu items are disabled when you have more than one package selected. I'm not sure how difficult this would be to implement, but I don't think it would be too hard. One way that you could achieve both use cases #1 and #2 right now (if you have VIPM Professional) would be to open the VI Package Configuration Editor and drag and drop packages from VIPM into the VI Package Configuration. Then you could double-click on a package in the VI Package Configuration editor and click Next to cycle through each of the packages in your configuration. You could easily remove VI Packages from your configuration, if you don't want them. When you are ready to install, you can Apply your VI Package Configuration to install all of the packages listed in the VI Package Configuration. Thanks for the great feedback. Also, if you want to evaluate VIPM Professional, feel free to contact us. We'd be happy to set you up with an evaluation license. Thank you, -Jim
  3. Hi Sylvain, That's great news! Let us know if you have any other issues or questions. Thanks, -Jim
  4. This is slightly tricky... The solution is to use the same name (label) for the numeric as you do for the array: Here is your example, fixed: take3256__fixed.vi By the way, this is covered in the Generating and Parsing Scalar XML Elements with Attributes article, under the List of Scalar Elements with Attributes section. Let me know if this makes sense and if you have any more questions. Thanks,
  5. Heiko, This one ends up being slightly more difficult, because the custom installation locations expect pathroots (e.g., , , etc.). We're planning to improve the usability of this feature in a future release. However, for the various other path controls on the Advanced Settings dialog, setting the Start Path is very easy and you can expect improvements there very soon Thanks, -Jim
  6. Hey Heiko, Thanks for the details on the various use cases: Palette Category Templates Editing Tools > do you have an idea how to create a category in the Control Palette? An MNU can (but doesn't have to) have one functions palette and one controls palette inside of it. I can help with this, off-line, if you want. > So maybe it is simpler to just continue using OpenG package builder for those cases. For an advanced user with highly custom use-cases that are not related to packaging and installing reuse libraries, I think you're right. That said, please continue to let us know about your use cases and ideas. We want to be able to include support for common packaging use cases inside VIPM and thus simplify the process. -Jim
  7. Hello Heiko, Thanks for the great idea -- configurable defaults would sure make things easier when you are creating new packages. Your solution, to have a "template" VI Package Source Folder (or ".vipb" file) that you use as a starting point for new packages is what we recommend for your use case. This is especially useful for organizations where one or more individuals might be creating new packages -- since, default settings would only apply to individual developers and not all developers in the team. Can you provide more information about the nature of the items that you are packaging? For example, what types of items are you packaging, where you need the "rsc" (vs. "lib") in the package name? If we can understand all the use cases, it would help us consider the design of this feature. Thanks, -Jim
  8. Hello Heiko, Thanks for the great feedback. > The browse buttons for the three Installation Folders under Advanced Build Parameters -> Installation Locations are all set to 'Select existing file' instead of 'Select existing folder'. Good catch. I've filed a bug for this, here: 5938 - Custom Installation Location file browse buttons should be set to "existing folder" > It would also be great if pressing the browse button would open the already typed folder, although that might mean having to handle the browse button separately. This is a great idea. This can easily be done by setting the Browse Options --> Start Path (which is a VI Server property of the Path control). 5939 - Installation Locations browse buttons should have start path set to current value Thanks, -Jim
  9. Please see our article, located here: Sharing VI Packages over the Network
  10. VIPM 2.0.1 has been released as a fix for some minor issues. Please see the VIPM 2.0.1 Release Notes page for more information. To download and install the latest version of VIPM, visit http://jkisoft.com/vipm/.
  11. You're very welcome. Please let us know if you have any other questions about how to use EasyXML in programming your application.
  12. Yes, the problem is that in LabVIEW 8.5 (and in 8.6, but I haven't tested 8.0 or 8.2) LabVIEW loses the array name at the For Loop. This can be fixed by adding a Variant to Data function after the For Loop to reset the array name to the one it had upstream of the For Loop. See the screenshot, below, for the fix. Thanks for your patience on this -- I was testing in LabVIEW 7.1, so I wasn't seeing the change in LabVIEW behavior I'll re-upload a fix for the example in the "Creating ordered elements in XML" article.
  13. I don't think that I see the same thing as you. For example, when I run the "Creating ordered elements in XML", I get: foo Can you please post a simple example VI that demonstrates your problem? This would help me understand what you are seeing and hopefully fix any problems. Thanks,
  14. Thanks for (re)posting your example. There are a couple things that should be mentioned: 1) How to handle attributes using EasyXML - please take a look at the Generating and Parsing Scalar XML Elements with Attributes article to see examples of some of the variations of how attributes can be handled in EasyXML. 2) How to create ordered elements in EasyXML - when an attribute (such as "xid", in your example) is used as an index, you can do some tricks to ensure that the items are ordered correctly in the LabVIEW array. See the Creating ordered elements in XML article for more details about this technique. Please let me know if these links (especially the Creating ordered elements in XML article) provide you with enough information to program your application or if you have an other questions. Thanks, -Jim
  15. Xrockyman, I don't see any attachment to your post. Can you retry posting your example and/or screenshot? Thanks, -Jim
  16. Thanks for the update. I'm happy to hear that it's working for you (and that you're finding it to be easy to use)! Thanks, -Jim
  17. Hi, You need to do two things: 1) Update Your Package List (this will ensure that VIPM can find/download the missing dependencies) From VIPM's toolbar, press the Check the Network for Available Packages button (shown below). VIPM will connect to the Internet and obtain an updated list of all the available packages. After VIPM completes this operation, you may see a dialog stating that there were new packages found and asking you if you want to install them. Press the no/cancel button and proceed to the next step. 2) Install the required dependencies OpenG String Library (oglib_string) 2.6 or greater OpenG LabVIEW Data Tools Library (oglib_lvdata) 2.8 or greater OpenG File Library (oglib_file) 2.8 or greater OpenG Error Handling Library (oglib_error) 2.3 or greater OpenG Array Library (oglib_array) 2.7 or greater OpenG Application Control Library (oglib_appcontrol) 2.9 or greater Please, let us know if this helps you get EasyXML working. Thanks, -Jim PS - The steps above were assembled from the installation instructions available, here.
  18. Hello Hans, I'm happy to hear that it's working for you, now. Yes, that sounds like quite a strange mystery. Maybe you rebooted the computer -- that often will fix a few things in Windows Thanks, -Jim
  19. Hello Hans-Juergen, I'm sorry to hear you're having installation trouble. Can you please confirm that three file paths identified in the error message are writable by your user account? The error seems to be due to the user account (under which the installer is being run) having insufficient access access rights. Can you also try right-clicking on the installer EXE and choosing "Run as..." to run the program as an administrator? Thanks, -Jim
  20. Hi Jeffrey, I'm sorry to hear about the installation trouble. Are you running on XP or Vista? Does your use account have administrator privileges? Does rebooting and trying again fix the problem? Can you run the OpenG VI, "Temporary Filename" (\user.lib\_OpenG.lib\file\file.llb\Temporary Filename__ogtk.vi), from within the LabVIEW development environment? How about if you change the value of the "sub directory" input (e.g., change it from "." to "test") and then run it? Thanks, -Jim
  21. Hi Chris, Keep me in the loop on your progress with the Category MNU file and let me know if you need any help getting this working -- your solution for using two MNU files might work, too, but you should be able to do it with one MNU (since MNU files can contain one Functions Palette and one Controls Palette). I'm here to help. Thanks, -Jim
  22. Hi Chris, I've been meaning and wanting to create that tutorial, since I know that there are at least a few of our power users out there who want to use that sort of setup. To do what you're after (have all your organization's libraries show up in a common sub-palette under User Libraries), you can simply set the the custom installation locations to the following: This will cause all of your libraries to show beneath a "OrganizationName" supalette of User Libraries (since LabVIEW will see a "OrganizationName" and create a dir.mnu file inside it that is synced to the "OrganizationName" folder). The only drawback of this "quick and dirty" technique, is that you won't have a pretty icon for your OrganizationName subpalette. However, you can always modify this mnu file and create a package that overwrites it (and make all your library packages depend on it, as described earlier). Thanks, -Jim
  23. Hi Chris, I'm happy to hear that you're on-board with VI Packages for your your VI reuse system First off, let's clarify what you're asking for: I assume that what you're wanting to do is create a root-level category in the Functions palette (similar to the OpenG palette, shown below), rather than having your palette installed in the standard locations (User Libraries, Instrument Drivers, Addons) supported by the VIPM's package builder? Doing this involves the following: 1] Create a special "palette package" You will need to use OpenG Package Builder to create a special "palette package" (e.g., called "org_rsc_palette", where "org" is the name of your organization and "rsc" is used to signify that that the package is a resource and not a library). There are a couple key things that should be noted about this package: The palette package should install a single MNU file (e.g., "org.mnu") into the "\menus\categories" folder (installing MNU files here causes them to show up as root-level categories). This palette (MNU) needs to be set to synchronize with the folder (e.g., \_org.lib\palette) where each of your library VI Packages will install their individual palette MNU files -- this is what causes each of your libraries' palettes to show up beneath your organization's palette category. Note that the underscore in "_org.lib" folder name is critical to avoid having all of your organization's library VIs show up in the User Libraries palette, which we do not want for this custom configuration. 2] Configure your library VI Packages for use with the "palette package" 2.a] Configure custom installation locations In each of your VI Package Configurations, you should configure custom Installation Locations, in the Advanced Build Parameters dialog, as shown below: Set the following parameters: Installation Location = . Library VIs Installation Folder = \_org.lib Functions Palette MNU Installation Folder = \_org.lib\palette Controls Palette MNU Installation Folder = \_org.lib\palette 2.b] Configure dependency on "palette package" We want to make sure that the library packages show up in the palette -- they depend on your palette package to achieve this. So, you will need to open the VI Package Configuration for your library VI Packages, by pressing the Open VI Package Configuration button on the Dependencies page of the Advanced Build Parameters, as shown below: Add to the "org_rsc_palette" package to your VI Package Configuration by dragging & dropping it from the VIPM main window's package list into the VI Package Configuration list, as shown below (note that your palette package must be added to VIPM's package list or installed, by this point): Save and close your VI Package Configuration. Re-open the Dependencies page of the Advanced Build Parameters, and you will see the palette package in the dependencies list, as shown below: Finally, make sure that that dependency is an External Dependency (rather than an Internal Dependency, which it is by default), as shown below: That should do the trick. Also, it's on our roadmap to add this sort of functionality into VIPM Professional. If you need any help creating your palette package (especially the MNU file), don't hesitate to ask. The process for creating this MNU file can be a little tricky -- Customizing the LabVIEW Palettes is (Ridiculously) Hard, you know Thanks, -Jim
  24. Hi Doug, I think you are stuck in a time warp! No, literally, I think that your computer's system clock time is wrong. Can you please confirm the date/time? If that doesn't work, then the issue might be that your Windows user account doesn't have permission to modify the C:\Windows\jki.conf file. Can you confirm that your user account has write access to this file? Please let me know if either of these solutions work for you. Thanks, -Jim
  25. Ya, it is a bit of a pain to uninstall a package that has dependencies, just to then re-install (repair) it. It takes a moment for VIPM to resolve the dependencies and then you have to unselect the dependencies in the action confirmation dialog.
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.