Jump to content

Jim Kring

JKI Team
  • Content Count

  • Joined

  • Last visited

  • Days Won


Everything posted by Jim Kring

  1. Hi Chris, I've added this to the known issues: Known Issue (Case 6273): Palette icon transparency not shown in package builder Thanks, -Jim
  2. JKI doesn't have access to the LabVIEW Software Engineering Tools beta, in order to test this issue. Is there a way to have this "evaluation software" dialog go away (such as a "don't show me again" checkbox) until after the beta expires? Otherwise, your manual work-around is probably the best approach.
  3. Neil, > Firstly, congratulations on what looks like a great VI utility. Thanks! Regarding your issue: That's strange. Does your Windows user account have admin rights? (Make sure you do.) Are you running anti-virus or anti-spyware software? (Try turning this off.) I'll check with the rest of the VIPM developer team to see if they have any other ideas. Thanks, -Jim
  4. Hi! Thank you for reporting this. Your right -- the palette sync option should be enabled by default in VIPM Professional. I've filed a bug here: Known Issue (Case 6238): Refresh LabVIEW Palettes After Package Installation option should be enabled (checked) by default for VIPM Professional users Thanks, -Jim
  5. Hi Jason, > I didn't prove that the beta tookits are the problem, but it worked fine on my other (albeit non-Vista) machines. When you say "beta toolkits" do you mean LabVIEW 8.6 beta or something else? > Also, the error message says "Make sure you are allowing access to VIPM by specifiying "*" in the allowed list. It would be a lot safer to tell people to allow "localhost" rather than "*". Thanks for the suggestion. I agree that we should recommend "localhost" instead of "*", as we do in the documentation, here: http://jkisoft.com/vipm/docs/2.0/?turl=labview8x.htm I've opened a bug (Case 6237) for this. Thanks, -Jim
  6. I know that this bug is on our radar, as I've heard others in JKI mention it. I'll find the bug ID and add it to the known issues. Thanks, -Jim
  7. Hi Brian, This was bug was discovered recently and is in the list of known issues, here: Known Issue (Case 6104): Editing LabVIEW TCP port can result in wrong settings changes when some LabVIEW versions are disabled Another easy work-around is to un-check and then rercheck the LabVIEW version checkbox (which will then open the port settings dialog). But, you're right -- you should always have all versions enabled Thanks, -Jim
  8. Hi All, Yes, this is a nasty Windows bug. We're all trying to figure out how best to deal with the problem. I'd say that the responsibility of a better error message falls on Windows, then LabVIEW, then VIPM. However, it would be really nice if VIPM gave you a better error message, especially since this problem seems to be happening pretty frequently. I'll file an issue and return with a tracking number. Thanks, -Jim
  9. Hi Brian, This is definitely a bug. I'll file it and report back with a tracking number. Thanks, -Jim
  10. Hi Richard, I've subscribed to the thread that you started on the NI forums and will keep my eye on it. Thanks, -Jim
  11. Hi Claude, The best solution is to configure your Proxy Server settings so that you can download the packages directly from within VIPM. If that doesn't work, you can get the jki_lib_state_machine package here and jki_rsc_toolkits_palette (a dependency) here. You'll want to install the jki_rsc_toolkits_palette package first. Thanks, -Jim
  12. Thanks (from the whole JKI Team)! We're looking forward to hearing your thoughts, after you've had a chance to take the JKI State Machine for a test drive and hopefully use it on a project or two. Thanks, -Jim
  13. Hi, There are some known issues related to installing VIPM on Windows Vista. Please see our FAQ on it, here: Can I install VIPM on Windows Vista? Also, can you try running the installer as Administrator? Also, you might try cleaning out your Temp folder before running VIPM's installer. Please let me know if this works for you. Thanks, -Jim
  14. Hi Ian, Thanks for taking the time to try out the JKI State Machine and for your feedback! The (relatively) short answer to your question is this... Think of the JKI State Machine as a foundational, fundamental structure that you can use to implement higher-level patterns. Sure the string-based state "queue" can be thought of as being produced and consumed by the JKI State Machine, but let's just ignore that for now and think about how we could use this structure for higher-level messaging between JKI State Machines. For example, we could use the JKI State Machine to create the following different structures: UI Event Consumer - In the JKI State Machine, subscribe to UI events, by registering for implicit events (in the Edit Events dialog) of controls on the Front Panel of the VI that contains the JKI State Machine. User (Dynamic) Event Producer - In the JKI State Machine, call Generate User Event to produce (publish) an event that one or more User Event Consumers is registered to receive (using a Register For Events function). User (Dynamic) Event Consumer - In the JKI State Machine, call Register For Events and the Dynamic Event Terminal to register the JKI State Machine's Event Structure to subscribe to User Events that are generated by some User Event Producer (or other location that might generate the event). If needed you can also uses Queues and Notifiers, rather than User (Dynamic) Events, to deal with the limitations that LabVIEW has in managing the UI Event and User Event "queues", such as the inability to flush or limit the size of the event "queues". Side note: IMO, this is a huge limitation that, if addressed, would make User Events much more... er... usable. One point that we should mention is that one JKI State Machine might fall into more than one of the categories, above. It should also be noted that these various JKI State Machine incarnations (above) can be encapsulated inside GOOP (object-oriented programming) or other by reference (including singleton) class/component design patterns. We'll be talking more about this, in the near future. Thanks, -Jim
  15. Oh, I see. Yes, when using the JKI State Machine as a Functional Global Variable (FGV) you might not even want an event structure at all. I'm looking forward to hearing about the tweaks you find useful for other scenarios, too. At some point, we'll want to create a catalog of how to implement various design patterns with the JKI State Machine. Thanks, -Jim
  16. Hi, I'm glad to hear that you're using the JKI State Machine in your projects. Here is a trick that I like to use, that might accomplish your goals in a slightly different way: Check if there are No Remaining States (no work on the queue). If so (no work), then wait forever for an event. Otherwise (if there is work still on the queue), check for events once (with a zero ms timeout). Then, when you are constructing work, you can interleave a "Check for Events" state (note that I have added the "Check for Events" string to the "Idle" frame of the state machine's Case Structure). This bit of logic makes sure that the state machine's loop is only executing when it needs to be doing work. Otherwise, it's just waiting for events. Now, if you really need to have wait states with specific timing requirements, you can either put a Wait (ms) function in your work state or have a "Wait" state that accepts a ms timeout argument, such as "Wait (ms) >> 100". Thanks, -Jim
  17. Hi Eric, Thanks for this feedback. Our intent for the licensing terms of the JKI State Machine template were as follows: If you create VIs from the JKI State Machine: you are free to distribute VIs that use the template, and you should have your users download the JKI State Machine package to obtain the support libraries. (While we do make our software freely available, we don't want other people hosting it for download.) Again, sorry for the confusion. We certainly want this to be a freely available tool for the community to use, and protect our users' rights as well as our own. We'll definitely run your concerns by our legal dept. for review. Thanks, -Jim
  18. Hi Brian, Thanks for the additional clarification and screenshots. You're 100% right about this -- we've got a bug on our hands. I've filed a bug and added it to the known issues: Known Issue (Case 6125): Installing package with missing dependencies doesn't show warning Thanks, -Jim
  19. Hi Steve, Sorry for the delay in response -- I just got back from the Boston NI Technical Symposium No, EasyXML doesn't handle parsing XML without an input data type. Can you post an example of your XML and how the schema change would break EasyXML? I'd love to brainstorm on how EasyXML could handle this situation. Thanks, -Jim
  20. Brian, Can you please tell us whether you see any warning in the Action Confirmation Dialog? I believe (with about 50% certainly) that VIPM does give you an indication that there are missing dependencies in this dialog. The should be grayed out with a status of "not found" (or similar). If it doesn't give this sort of indicator, then, yes, this is a major bug. However, VIPM should still allow you to install a package that has missing dependencies. The use case for this is when you need a VI in a package that doesn't actually have a dependency on the missing package (since it only takes one VI in a package that depends on another package to create a dependency). Thanks, -Jim
  21. Hi Brian, This is a great suggestion! Currently, there are extensive dependency management features in the VI Package Configuration Editor window, when using VI Package Configurations. Currently, however, the main VIPM window does not show missing dependencies. It's definitely on our road map to add dependency management to the main VIPM window. In the interim, please try to use VI Package Configurations for all your LabVIEW projects. Here's the process we recommend: 1) Apply your VI Package Configuration before starting work on a project --> this ensures that you have all the latest packages installed and that there are no missing dependencies. 2) Scan your project for VI Packages, occasionally, when working on a project --> this ensures that you have all the packages being used on your project in your VI Package Configuration. Thanks, -Jim
  22. Hi Matthew, First, I'm sorry that it took so long to respond. I was traveling to the Boston NITS event when you posted. I'm happy to hear that you got it working. There are a couple possible "root causes": 1) It might have been a permissions issue with files/folders in the Temp directory 2) It might have been that there were files in the Temp directory that were "in the way" and even though VIPM had permission to delete them, it wasn't trying to delete them before writing. If the problem was #2, then this might affect all users -- not just Vista. I'll take a look under the hood and see if I can find anything that looks suspect. Thanks, -Jim
  23. You're welcome. I'm glad to hear that you were able to get it working.
  24. Hi François, First, thanks for upgrading to Professional! That's a great suggestion and I'll pass it along to the VIPM developer team. In the meantime you might try the following: Keep all your polymorphic instances in a subfolder that is prefixed with an underscore (VIPM's auto-generated palettes will ignore all folders and VIs that whose name begins with an underscore). For example: \Filter 1D Array.vi \_Filter 1D Array\Filter 1D Array (DBL).vi \_Filter 1D Array\Filter 1D Array (String).vi \_Filter 1D Array\Filter 1D Array (Boolean).vi Would this work-around fit your development practices? Thanks, -Jim
  25. Hi, You can download the OpenG Packages, individually, here: http://sourceforge.net/projects/opengtoolkit/ There are also some links here: http://wiki.openg.org/Category:OpenG_Packages Once you have the packages, you can add them to VIPM's package list using the File>>Add Packages menu option. Thanks, -Jim
  • Create New...

Important Information

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