Jump to content


  • Content Count

  • Joined

  • Last visited

  • Days Won


Daklu last won the day on August 7 2019

Daklu had the most liked content!

Community Reputation

1 Neutral
  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 (Feb 11 2019)".] [Edit 2 - Another piece of potentially relevant information is the Test_ListImp..._2 test class was brought forward from an older version of VI Tester. I don't know what version, but according to my repository it was sometime before Feb. 2013. The other test class (the one that passed) was created with the current version of VI Tester.] VI Tester Error.zip
  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- 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 speaking from personal experience... I have no idea what you're talking about. ) Because I'm not ready to open the can of worms of writing custom serialization and mutation methods for all my classes. As an app developer I can analyze the specific requirements and focus on serialization/mutation code for a few classes that need to be persisted. As an api developer I don't know what other developers will want to do with the components I've created, so I assume someone will need to persist the component's state to disk. Stepping on the dependent objects' mutation history while building that package make it harder to allow users to do that. My package source can't use the read/write to disk prims directly on the objects, so I can try manually decomposing all the dependent objects into their native data types and save those instead. Not only is that a pain, but it makes client code dependent on implementation details that are better kept private, and if any data is private it won't work. So since using the read/write prims isn't an option, and decomposing the object isn't an option, that leaves me with writing serialization methods for all my public objects. If a library's namespace could be changed and the mutation history preserved (and I was really careful with my coding) I could at least avoid writing serialization methods for data-only classes (those with no references) and still guarantee forward compatibility for users.
  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 assign all the Support destination content to a new library? So if my reuse library was named Messaging.lvlib, now it will be Support.lvlib:Messaging.lvlib, correct? "Run my build script that adds the support Project Library to top level Project Library" Now the private reuse code has the MyPackage.lvlib:Support.lvlib:Messaging.lvlib namespace, right? I think this will do what I'm asking for. I do wish I didn't have to trash the mutation history of the messaging library, but there's not much we can do about that.
  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 separating namespacing (and mutation history) from library membership there may not be a good way to reliably handle what I'm trying to do. Even what I proposed has limitations to what end users can do with the new reuse package.
  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 contain and link to the private reuse code, or will it end up linking to private reuse code that now is part of my source code library? (I vaguely remember running into a similar issue a while back with ogpb.) Thanks, Dave
  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 files and have it install them to the correct locations on the target computer.
  • Create New...

Important Information

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