Jump to content

dcoons

Members
  • Posts

    12
  • Joined

  • Last visited

  • Days Won

    1

Posts posted by dcoons

  1. On 1/24/2024 at 3:43 AM, Mads said:

    Now that 2024 Q1 is released maybe we can just skip to that 😮 It will be interesting to see if the issues highlighted in this thread has been resolved(?).

    @Mads I could not get builds for installers/packages to work in 2023Q3 either. It would hang forever until I killed the process with task manager or would finally pop up an error saying: "Error generating preview for executable" even though the EXE would successfully build. I found a few articles talking about this (https://knowledge.ni.com/KnowledgeArticleDetails?id=kA00Z000000P8m4SAC&l=en-US) but it definitely wasn't a dependency mapping issue. I tried clearing the compiled cache and building over and over and over and over again to no avail. But, alas, upgrading to 2024Q1 did fix the issue. I am not quite sure what the instability was, but it built with no issues and no changes in 2024Q1. 

    Hopefully this helps someone in the future!

  2. Hello All,

    I am trying to apply some principles to dynamically theme a UI in LabVIEW a la Google Material (https://m3.material.io/). I have created a theme class to define the different color schemes for the different situations (light mode, dark mode, whatever else) after loaded from a file. I am getting things to work pretty well overall EXCEPT I cannot find a good way to change the following colors:

    • Listbox: border (the blue box surrounding the two listboxes shown in the screenshot)
    • MulticolumnListbox: border (gray in the screenshots so not too big of a deal)
    • MulticolumnListbox: horizontal lines (cannot see anything that implies dynamic coloring for this)

    I will go ahead and attach the VI but I doubt it will be very useful for figuring this out - all the coloring will happen via another VI. I just need to figure out the properties to make this happen. Or to be gently let down by telling me it isn't possible for those items and I have to figure out a work around........

     

    side note, this is not where things will actually be put on the screen, so don't get bogged down in that weird detail :D

    dark theme.PNG

    light theme.PNG

    test vi to theme.vi

    • Like 1
  3. Has anyone used the functions located in vi.lib to programmatically edit Installer build specifications? I have used the functions in AB_API to edit Packed Project Library build specifications (in PPL subfolder) but cannot find anything equivalent for Installers. The classes in this hierarchy inherit from NI_AB_API_Build.lvclass which has a generic open method, but installer is not in the list of selectable build types to open.

    I also found IB_Classes subfolder which has functions for interacting with Installers maybe, but there's no clear function to open an Installer build specification to start editing. I have a template project where I need to change three parameters for the Installer when the template is copied/edited: destination.name for one specific destination, INST_bldLocation, and INST_productName.

    This is an example of updating a few of the build specification items for a PPL (just need the equivalent for installers):

    image.png.3b6cfa79f7a2b94e27a388652cc6ce19.png

  4. As an update, here is an example code project demonstrating to a minimal degree what I am trying to accomplish.  In this case the VIPM package will go to user.lib, but the same issue still applies.  (Also, I made a .vip file, but you can just take the built packed library and put it into user.lib instead of using the package and it will still demonstrate the issues)

    -Common Code has a reuse function I want to use and it is built into a packed library

    -Parent defines a parent class that uses a function from common code and is built into a packed library

    -Child class inherits from Parent but Parent is Not Loaded and breaks Child class

    vi.lib reuse issue.zip

  5. Inspired by my question from this post: link, I started off on a path of packaging project dependencies into vi.lib as suggested by @smithd and @Darren  however I have started down a rabbit hole of packed project library (ppl, *.lvlibp) head scratchers that have left me a little confused on what is going on in the background. Most of my components are built into packed libraries because I am following plugin models for extensibility when building as an EXE.  To make packed libraries work with dependencies, you basically have to build those into packed libraries as well to avoid the namespace issues.

    I used VIPM to create packages to distribute some of this shared code to vi.lib.  In the example below, I created a packed library (Controls.lvlibp) and packaged it to vi.lib for use.  In the Limits project in the image, I am using the Controls library in a few of the functions. Limits also contains a build specification to create a packed library for a component.  However, I first noticed an issue when I looked at my child class projects (that inherit from the Limits.lvlibp:Limits.lvclass).

    image.png.bf047ca37290771fcd30a2f057978145.png

    The Limits.lvlibp is showing as Not Loaded. When I go directly to the library on disk and try to open it, I get the message "Project or Library file cannot be opened." I notice that if I get the correct Controls.lvlibp into memory by opening it up or by putting one of its VIs on a block diagram, then the library will load correctly.  So, I know it has something to do with when data from vi.lib is loaded into memory, but I don't know how to force it into memory to get this to work correctly.  Generally I am selecting the option to "Exclude dependent packed libraries" in my build specifications, but if I leave that unchecked it will open properly (because it places the dependency directly next to where it is built).  I did not have these issues until I placed my shared components into vi.lib, so I would be grateful for any help to help me debug this!

    image.png.7d268e2fbbb3335d91ff8a82cb602a17.png

  6. On 10/12/2018 at 4:26 PM, smithd said:

    I've never done it that way, for shared dependencies I've always made packages and installed them into vi.lib, which eliminates the problem. I don't think there is an easy fix.

    The fix I can think of is that there are several steps to the sample project: a dialog is displayed, then it copies the sample project into a new location, then it runs any post-copy scripting code. My suggestion would be to ask your users, in the dialog, where their 'root' project directory is. You can then through either the default value vi, or that same VI loaded up in a more appropriate application context (you may need the super secret ini key turned on to find the right one), get the ancestor classes loaded in from the appropriate path. Once they are loaded, and you reach the copy part of the script, labview should accept that they are the right ones (it might fuss that dependencies were found in the wrong location, but it should work).

    I think I am comfortable with the idea of creating packages and putting into vi.lib - that is a good idea except there is one dependency library that is a little different.  The one that I am not sure about is a plug-in type that loads the correct child plug-in based on the configuration file for the application.  So for that one I would still need to do a little directory trickery.  I will do a little playing around and see what I can get to work (and I will try to remember to reply back with how I handled it).

  7. For a lot of my LabVIEW projects, I have been developing scripting tools to help team members get to a good starting point for their code or to remove human error when following templates.  After seeing Becky Linton's presentation at NI Week in 2016 (link), I was inspired to use Project Templates to make it a little easier for the developers to get to.  I have been able to get it to work to varying degrees at this point, but I have a question on how to handle project-specific dependencies.

    If I have a team working on a larger development project that has shared core code and we have it in a repository, everyone on the team usually puts the cloned source on a different location on disk.  If my scripting tools have a dependency on code in that repository (class ancestor is biggest), then its location would move from development machine to development machine.  Therefore, if I put my tools into the LabVIEW\ProjectTemplates directory, those dependencies would need to re-map for every user and that defeats the benefit to having it be a part of the Getting Started window - at that point it is easier just to point them to the scripting wizards that are pulled with the rest of the code from the repository. 

    Does anyone have a good suggestion for how to accomplish a good structure with project-specific dependencies?  Or am I trying to fit a square peg into a round hole for this type of application?

×
×
  • Create New...

Important Information

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