Jump to content

Daklu

Members
  • Content Count

    36
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by Daklu


  1. 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

    Capture.PNG.741e85a381e319a7d0ef3e5fb445f83d.PNG

     

    testCount.vi

    Capture.PNG.e2ac12e4eab595da7b883fdc2a39e5ae.PNG

     

    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 (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.] 

    Capture.PNG.f4462ebacda0c08e87070338b0e57aa4.PNG

    VI Tester Error.zip

    • Like 1

  2. It would also be nice if the standard template would have bit more space and that everything is lined up correctly

    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.)


  3. Update: I was able to build a working version of your package (no "dings" :)) by opening your project, doing a Save All, and then building the package.

    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...)


  4. 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


  5. VIPM sucks dependancies, which have not been defined as external, into the package automatically. Not into any LabVIEW library. It does auto-namespacing and relinking of those VIs for you. For namespacing we use a GUID.

     

    Yes, those namespaced VIs are publicly accessible. As I mentioned earlier. We don't have any ability currently to make them Private. However, this would be a feature we could consider if you find it useful. <snip>

     

    It seems like your need is finding a way to protect the dependancies from end users in a more controlled fashion.

    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. :unsure: )

     

     

    Why is it important to maintain the mutation history?

    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.


  6. Sorry for the stupid questions.

    Totally NOT stupid questions!

     

     

    • These dependent libraries, you talk about. Are they beneath vilib?
    • Have they already been packaged and installed using VIPM?

    If the answer to the above is YES. Then I think you can just remove them as dependancies during the VIPM package build process and VIPM will automatically suck them into the package and do the relinking for you.

    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?


  7. It says "LabVIEW Project" not "LabVIEW Project Library"

    Yep... I was misunderstanding your process. :blink:

     

    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.


  8. I have posted this before I think but here is how I do it:

     

    [*]Add all the reuse VIs that will be made private to it, normally done by dragging and dropping from the dependencies item in the LabVIEW Project

    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.


  9. (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


  10. Would such a tool need to be able to uninstall/upgrade packages on the target system?

    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'? :lol:


  11. 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.


  12. 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


  13. 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.)


  14. I really like the new palette editor in VIPM 2010. However, instead of creating a .mnu file it stores the palette information in the .vipb file and creates the .mnu file when the package is installed. That's clearly a better design, but it also makes it a little harder to use that palette file as the default palette for classes and libraries.

     

    Pre- and post-build scripts are only available in the pro edition. Is there a good way to do this using the community edition?


  15. So I was playing around with building packages in VIPM 2010 and I ran across a bug in the package versioning. The package version number contains the build number except for the very first time the package is built. That package has the build number 0 removed.

     

    This appears to confuse VIPM with respect to which version is the most recent. More recent builds with the same Major.Minor.Bugfix numbers aren't consistently identified as an update.

     

    post-2450-1281458574.png

     

    Even though I have the most recent version installed, the icon on the left indicates an upgrade is available. Selecting Upgrade... from the context menu prompts me to install v1.0.0. The Action column in the dialog box does correctly identify it as a downgrade though.


  16. Here's how we do it. Please check out the attached example:

     

    Thanks Jim. This is very helpful.

     

    (Note to other users: The examples also depend on the oglib_file and oglib_picture packages.)

     

     

     

    [Edit]

    I noticed NI has recently(?) suggested distributing code to vi.lib instead of user.lib. Do you have any insight into why this is? The only practical difference I can see (ignoring the auto-populating user palette) is the source control configuration includes the option to exclude vi.lib but not user.lib.


  17. I've been using VIPM Pro to try to create a dyanmic palette package that would install a single synchronized .mnu file to <menus>\Categories. This technique has been described in other threads and I believe it's how the OpenG and JKI Toolkits menus work. When running Windows 7 and LV2009 the installation fails with the following error text, though it does not generate an error log:

     

    Main Package Name: menus_lib_test_vipm_package-1.0.0-1

    Package Name with Error: menus_lib_test_vipm_package-1.0.0-1

    Error Message: VIPM could not install the package menus_lib_test_vipm_package-1.0.0-1 .

    Error Code: 1

    Error Source: Create Folder in Create Dir if Non-Existant__ogtk.vi->ZLIB Read Compressed File__ogtk.vi->VIPM ZLIB Extract File (Optimized).vi->F708E1932FBA2EC75169814B1C5ED2A8->8E3829D02DE8A62074DD090AE0A0E188->33516115B17A724501600154F5A39EDF.lvlib:AA082459946BE4C53B30C4CBCDFD0679->33516115B17A724501600154F5A39EDF.lvlib:7E5E9B93FA8C8DD25F25EF42ADB93E18->21B089D9C08E3EF4FD4D10088FFAEAAA->VIPM Main Window.vi

    ===============

     

    I thought it might have something to do with UAC not allowing writes to the Program Files directory, so I tried the following:

     

    - Created a duplicate package that installed the palette to user.lib instead. This installs correctly.

    - Run VIPM with administrator rights. Install still fails.

    - Uninstalled and reinstalled the JKI Toolkits palette, which also uses the Categories folder. It worked fine.

     

    So I examined the spec files in the cache and found this...

     

    post-2450-1269620418_thumb.png

     

    The spec file on the right is the one for my test package. Notice the invalid path defined in Target Dir. To make sure I had actually set up the build correctly I double checked the installation locations and rebuilt the package with the same result.

     

    post-2450-1269620744_thumb.png

     

    I also configured and built a similar package using OGPB that did NOT exhibit this problem. All three packages are included.

     

    menu_test_ogpb_package_1.0_1.ogp

    menus_lib_test_vipm_package_1.0.0_1.vip

    userlib_lib_test_vipm_package_1.0.0_1.vip


  18. The runtime error you are seeing is because the way that we find tests to show on the VI Tester UI is via 'introspection' and it just happens that we're searching for VIs named test*.vi and test*.vit is being found as a 'match'.

     

    FWIW the error doesn't seem to hurt anything. I suppose I could just go into <Labview>\resource\JKI\VI Tester\Templates\TestCase and rename textExample.vi to Example.vit. Then I wouldn't have to rename it at all for new test cases.


  19. When I create a new test case class the first thing I do is rename testExample.vi to textExample.vit. That simplifies my work flow a bit for a couple reasons:

     

    1. I can right click the template and use "New From Template" instead of going through the rename dialog box. Easier and faster.

    2. The testExample unit test doesn't show up as an available test so it isn't executed and my test results aren't all cluttered up.

     

    Changing it to a template does raise an error when I start VI Tester. Any chance of 'officially' changing testExample to a template?

     

    post-2450-1250006054.png

×
×
  • Create New...

Important Information

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