Jump to content

Daklu

Members
  • Content Count

    36
  • Joined

  • Last visited

  • Days Won

    3

Daklu last won the day on August 7 2019

Daklu had the most liked content!

Community Reputation

1 Neutral

1 Follower

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

  1. BTW, (and not related to this thread in any way whatsoever...) I cloned the repo to see if I could implement the changes for Issue #40 . Package 3.0.2 is available on VIPM. Should that branch be merged into master or do you have other plans? (I'm wondering if I should branch from master or 95c579a.)
  2. Thanks Jim. It's not urgent, but I wanted to let you know about it. Once I figured out it was related to classes being created in a previous version of VI Tester it was easy enough to work around.
  3. I ran across a problem in a project where, after creating and initializing the class under test in the setUp VI, unbundling it in the test VI returns a default object rather than the one I instantiated. setUp.vi testCount.vi I've attached a project with the class under test (ListImp) and two test cases. Both test cases have (as near as I can tell) identical setUp code and identical code in the test method (testCount). However, one test passes while the other test fails. Any idea what's causing this? [Edit - The about box reports "version 3.0.1.294
  4. Or better yet, allow us to replace the default template with our own templates. (FYI, test cases are usually similar enough that I create new ones by opening an existing test case and selecting "Save As..." rather than starting from scratch every time.)
  5. I looked around but didn't see this noted anywhere... If you try to sort on an unnamed column by clicking the header all the packages disappear from the list. Clicking on a named column header brings them back.
  6. What happened to the "How'd they do that?" thread? I could have sworn I saw it just the other day, but I've scoured the website and can't find it...
  7. Thanks for looking into that Jim. It didn't even occur to me that the built code would be broken when the source wasn't. Odd. Sometimes I think LV is starting to lose a few screws in it's old age. (That's the lie I tell myself to so I don't start thinking it's me...)
  8. In the attached package, I have created independent .ctl files for each of my classes so I can put class controls on the controls palette. Most of them work, however the links for the Message class and the ErrorMessage class (the first two on the second row) just *ding* at me when I try to select them. I did move around some of the source code and broke the palette links, but I went back and recreated them with the new locations. The mnu file appears to be set up correctly. Any idea why these two controls can't be used? lapdog_message_library-1.2.0.19.vip LD Msg Lib src.zip
  9. Ahh... I didn't know VIPM did this. My primary goals are: 1. Eliminate dependencies between packages as much as possible, and 2. Avoid namespacing conflicts. Importing the dependencies into the package's library seemed like the most logical way to do that, but what you've done solves the problem too. Thanks for the tip! At the moment I don't have a pressing need for the dependent libraries to be private. Mainly it's to prevent boneheaded mistakes like having users accidentally link to the dependent library by draging and dropping from an open block diagram. (No, I'm not spea
  10. Totally NOT stupid questions! Yes to both questions... I'll have to try that out. One thing though, does VIPM suck the dependent libraries into the *package* or into the *library* I'm deploying with my package? And if it just sucks them into the package, doesn't that leave me with two publicly accessable copies of the same library (possibly with slightly different implementations) installed in vilib? Or does VIPM automatically do some namespacing magic on the dependent libraries on it's own?
  11. Yep... I was misunderstanding your process. Can you clarify a couple more steps for me? I'm not quite sure I'm following what you do. "NI Builder assign the support folder to a Project Library during the build process" I take it you create a Source Distribution build in the project? I don't see a way to directly assign a virtual folder to a project library during the build. It (as far as I can tell) can only be done for an entire destination directory. Do you send all your reuse code in the Support virtual folder to the Support build destination (or custom destination), and
  12. I may not be understanding your process correctly, but this step worries me. If you're importing the classes residing in your reuse directory to a project-specific library, your reuse code--which is supposed to be independent--becomes dependent on that project-specific library. I suppose you could do the build then remove the reuse library from the project-specific library, but in the meantime the namespace changes to your reuse code has reset the mutation history of any classes in that library. That can be big problems for other users and other applications. Until NI gets around to sep
  13. (The question arose while I was composing this message on Lava.) I'd like to automate the process of importing dependent libraries into a package during the build process. Users don't need to know about the dependent libraries, so I'd like to make them private members of the library I'm actually building. I figured a pre-build script should do the job, but I realized it might not be possible. As I understand it VIPM creates a separate app instance and copies the source code during the build process. If I follow the steps outlined in my post on Lava, will the resulting package contai
  14. Uninstall? Yeah, you can bet if it wasn't there someone would object. Upgrade? Meh... if the tool is smart enough to show me what packages are on the target system and forces me to uninstall them before I can install new ones, that'd be fine. As long as the tool itself doesn't require installation I'm pretty flexible. Just so you know, I don't think this something we would use very frequently. Maybe a dozen times a year or so. (Unfortunately there are a lot of barriers to break down when trying to get people to change...) Can I coin a name for it? How about 'VIPM On-The-Go'?
  15. One of the pain points for us in using VIPM is that it has to be installed on the pc that has the Labview source code. I have peers who resist adopting VIPM and prefer copy-and-paste reuse for this very reason. Having a lightweight executable that can be run from a memory stick and is able to install/uninstall packages to the target Labview directory would be a big help in overcoming their objections. I'm not looking for a full-fledged version of VIPM that stores different package versions, scans projects for packages, etc.; just a small executable that I can point to some .vip or .vipc
×
×
  • Create New...

Important Information

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