Jump to content

Francois Normandin

Members
  • Content Count

    21
  • Joined

  • Last visited

Everything posted by Francois Normandin

  1. Hummm, lately I tried to put the classes in llb files and I got errors that VIPM could not detect the LabVIEW version of the files. At first, I attributed that to a file corruption and I took the VIs out of the llb when I resaved them. I thought that was it, but I reput it in a llb and couldn't build again. If I can make it work with LLBs, I'd be glad to do it. Does it mean I need to deploy with "Destination Type" == Directory ?
  2. Has this issue been resolved? If not, is there a known workaround? I'm thinking about putting the child class in a separate package but I don't know if I'll have problems with namespacing, and I find it's not a very efficient way if I want to distribute my plugins all separate: it could make for an impressive number of packages. It probably would anoy people if I started posting these on LVTN for example... Just a thought, would it be possible to change the filenames in the package as a pre-build instruction and rename them with proper namespacing on install? François.
  3. Thanks Jim. Now that you explain it, I remember during the beta tests that it was mentioned. I just forgot what form it would take in real life! So it's obvious that the PNGs that serve for the creation of customized controls don't have to be reintalled/uninstalled for each LabVIEW version. Clever.
  4. This is the first time I build a package that takes two lines in VIPM. The second is named identically with a reference to (System) and is an auto-dependency. It seems to work fine and I see it happens with stuff on the LabVIEW Network. What does it mean? http://screencast.com/t/ODIzODBiZjkt
  5. Hi folks, I'm trying to come up with a way to build packages that will add some controls or functions to an already existing palette created with a previously built package. This would be like some sort of "Expansion packs" to extend functionality of a library. I realize I'm talking about dependencies and VIPM deals with that quite transparently, but here's the twist: I want to have these palettes expand much like the OpenG palettes... that use dynamic palettes. How can I access similar functionality for my packages without using a post-built installer? I'm not sure I make sense... EDIT: I should add that I use a directory that begins with an underscore that prevents LabVIEW from scanning the menu files inside. Removing the underscore is my current workaround... EDIT (bis): Setting the directory to Synchronize = True would work. I tried to change it manually in the vipb file, to no avail. Is it a future feature?
  6. Cool indeed. Chris, you seem more happy than I am... thanks Jim. [Long shot] What about VIPM 2.x? [/Long shot]
  7. Hi Philippe, actually, I would still like to know if there are any VIPM 2.x updates available. (Of course, there might not be any...) Unchecking this bullet will remove any notifications. Well, I'll get the news of new updates from the RSS feeds anyway, so it's a good workaround. thanks, François
  8. Hi JKIs, I'm working with VIPM 2.0.3 Professionnal and hasn't received funds to update to version 3 as of now. If I update without upgrading my support plan, I'll have to downgrade to Community edition. Is there a way to have VIPM not look for version 3 updates if I have a Pro Edition?
  9. Is there anyway in the meantime to do it from a command line?
  10. No reason other then I installed everything that was in the list... Thanks for the info.
  11. I've upgraded to VIPM 3.0 Community at home, and I get the following conflict when I want to install ogrsc_deab package. (LV2009) Also, as a side-effect, if I select multiple packages to be installed and this one is selected, the whole installation process aborts and no packages get installed... (no error messages)
  12. I'd like that too... With more and more packages being built for LAVA, I had briefly discussed without Michael the option of having a LAVA icon in the palette to put the code shared in the LAVAcr.
  13. I don't know if there are other fixes needed for it to work in every case, but I managed to get it to work by modifying these two VIs: Find VI Hierarchy__ogb.vi >> Filtering out the array from VI.Callees to remove self prevents from entering an infinite loop. Sort VI Hierarchy__ogb.vi >> Had problems sorting out because Caller and Callee Links had duplicate pointers. Removing the callers links from the callees links clears the problem. Find_VI_Hierarchy__ogb.vi Sort_VI_Hierarchy__ogb.vi
  14. Something along those lines. The only clue I've got (haven't tried to correct it myself) is that one of my two CPUs is running 100% until I stop the process, so there's a condition to add to stop that loop. I'm sure it's not a serious bug and that a fix will be easily implemented. thanks, François.
  15. I just tested it and I confirm it works. No other problems during build, apart from unrelated issue of recursive VI... :-)
  16. I've implemented a very simple VI in LV2009 using recursion and I can't package it. The OpenG builder waits infinitely for the VI to load in memory, thus preventing VIPM to complete its tasks. I don't get error log because I need to abort the execution with Task Manager. But I stripped down my package to include only the recursive VI and the OpenG builder progress bar gets stuck until I kill the process.
  17. If this FGV design works good for me, I'll report my experience in "Tips & Tricks".
  18. Thanks Jim for the tips. I will surely modify this template for many different applications. This particular example was for a modification to use the template as a FGV (note the Data:Initialize only on first call). I needed it to execute without delay and exit right away. But you're right, my problem is easily managed with Wait (ms) >> xyz. I don't really need all this overhead for a FGV, but I liked the idea of error handling, cleanup, etc. since speed is not an issue.
  19. Hey guys, I've played around with "JKI - String-Based Queued State Machine (Basic) v1.0" template and I find it really useful. I'm implementing it in many of my new code. As I'm sure this is not the last version we see of this, may I suggest this simple addition for the next version? Adding "Timeout" to the Core Cluster & "UI: Timeout" to control it. To have the ability to change timeout on the fly like UI: Timeout >> 100 command would be really useful.
  20. Thanks Jim, It sure would. Once I know that's the way it was designed to respond, I'll adapt my naming practices to match.
  21. Hi guys, I have recently upgraded to Professional version and began to test packaging some reuse librairies I have. One thing that took me a lot of time was getting rid of all the polymorphic VI's from the function palette. I generally don't want to see a list of Get_###(U32).vi in there. It would be great to have an option that excludes them, but still keep the generic VI. (ex: Get_###(Polymorphic).vi) François.
×
×
  • Create New...

Important Information

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