Jump to content

Jim Kring

JKI Team
  • Content Count

    1,726
  • Joined

  • Last visited

  • Days Won

    42

Everything posted by Jim Kring

  1. 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/.
  2. You're very welcome. Please let us know if you have any other questions about how to use EasyXML in programming your application.
  3. 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.
  4. 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,
  5. 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
  6. Xrockyman, I don't see any attachment to your post. Can you retry posting your example and/or screenshot? Thanks, -Jim
  7. 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
  8. 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.
  9. 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
  10. 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
  11. 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
  12. 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
  13. 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
  14. 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
  15. 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
  16. 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.
  17. Thanks for the extra info. We'll discuss this feature with the VIPM team.
  18. Hi Ton, That's a great idea -- we've noticed that we need that feature, too. It's on our roadmap. Thanks, -Jim
  19. That's a great idea -- I've filed it: Case 5877 - When launching VIPM from LabVIEW, VIPM should switch to that version LabVIEW I should make it into a future release.
  20. We are excited to announce the final release of VIPM 2.0. This concludes the release candidate period and includes improvements resulting for your hard work in testing and providing us with feedback -- thank you! Please see the VIPM (2.0) Final Release Notes page for more information about the improvements made in this release. To download and install VIPM 2.0, visit http://jkisoft.com/vipm/.
  21. Hi, Thank you for the kind offer to translate the package building guide. For various reasons, we can't have our documentation published on other websites or forums. Do you see a large demand for these documents in Russian and/or German? If so, we will consider putting translations up on our website that you can link to from other websites and forums. We are very interested to know how we can better serve VIPM users who do not speak English. Your input and help in reaching these VIPM users is greatly appreciated. Thank you, -Jim
  22. Hi Ton, That's a clever idea. It does have several complications which would make it very difficult to achieve. In addition to access to the file system of the remote machine, we need the ability to launch LabVIEW -- this would be very difficult on a remote machine.
  23. That's an interesting idea -- what sort of customizations/changes would you make?
  24. Hi Ton, > Since it's the postpackage VI that shouldn't be a problem (and it isn't, see below). Oops... you're right. The pre-package and post-package VIs aren't included in the package: only the pre-install and post-install VIs are included. > That fixed it, renaming the ico file to bmp it all worked like a charm. That's great news. I'm glad that you were able to get your package working! Thanks,
  25. Hi Ton, Did you create this package with OpenG Package Builder? There are two problems with the package, that I can see: 1) The package does not contain the post build script VI, "PostPackage.vi", that is declared by the package spec. 2) The package icon should be a BMP file (take a look inside any of the OpenG toolkit packages), not an ICO file. Thanks, -Jim
×
×
  • Create New...

Important Information

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