Jump to content

Daklu

Members
  • Content count

    33
  • Joined

  • Last visited

  • Days Won

    2

Daklu last won the day on March 4 2013

Daklu had the most liked content!

Community Reputation

0 Neutral
  1. Suggestion: testExample.vit

    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.)
  2. 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.
  3. 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...
  4. 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...)
  5. 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
  6. 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.
  7. 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?
  8. 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.
  9. 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.
  10. (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
  11. 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'?
  12. 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.
  13. I'm attempting to build a package from a project that contains two libraries, each of which has 3-4 classes. It also includes a handful of dlls, two of which are .Net assemblies and referenced by the classes. The other dlls are support files the assemblies depend on. If I attempt to include either of the libraries in the build it fails. Excluding the libraries but building with just the dlls works, but of course isn't very useful to me. The libraries and classes don't do anything particularly special. I've attached the associated error file. Let me know if you want to look at source code. I can't post it publicly but we could make arrangements to transfer it via email or secure ftp. -Dave October_06_2010.txt
  14. First off, I absolutely love the palette builder functionality in VIPM. It's far easier to use than NI's methods for building palettes. After using it for a while with several packages I do wish I had the ability to copy items from one palette directly to another palette. I often have multiple copies of the palette open while I'm arranging the layout of a palette tree. Sometimes I want the same vi to show up in two different palettes in the tree. Instinctively I tried ctrl-click-drag to see if it copied the vi to the new palette, but it didn't. (Being able to copy an entire subpalette to a different location would be really handy.)
  15. I'd love to be a pro user. We'll have to wait to see what the bean counters say...
×

Important Information

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