LabVIEW Idea Exchange

About LabVIEW Idea Exchange

Have a LabVIEW Idea?

  1. Browse by label or search in the LabVIEW Idea Exchange to see if your idea has previously been submitted. If your idea exists be sure to vote for the idea by giving it kudos to indicate your approval!
  2. If your idea has not been submitted click Post New Idea to submit a product idea to the LabVIEW Idea Exchange. Be sure to submit a separate post for each idea.
  3. Watch as the community gives your idea kudos and adds their input.
  4. As NI R&D considers the idea, they will change the idea status.
  5. Give kudos to other ideas that you would like to see in a future version of LabVIEW!
cancel
Showing results for 
Search instead for 
Did you mean: 
0 Kudos
Mads

Projects should be able to ignore that a file is a VI or .llb

Status: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

I often need to build applications and installers that include VIs or .LLBs that have been built  earlier on...but this is a major pain because as long as LabVIEW recognises the file type it will try to link the VI or VIs in the library to the other VIs in the project, it finds conflicts etc. There are ways to come around it yes, but not very elegant ones.

 

Basically what I want is for projects to be able to treat VIs and LLB files as non-LabVIEW files. Just like you can include a text file, a JPG picture or other files in your project and installers I want it to be simple to add "completed" LabVIEW files.

 

One solution could be to have another type of project folder. We have auto-populating folders...perhaps we could have a folder for pre-compiled / to be treated as external sources folder...? In most cases for me LabVIEW could just see that the file does not contain any source code and then treat it as a "dead" file..or at least give you the option to do so (if there is a potential conflict).

9 Comments
AristosQueue
Proven Zealot

What is the use case for this? If those files cannot be used in conjunction with your current project -- because you have two VIs of the same name -- when would you ever be able to load them together in the resulting build? What you are proposing describes exactly the situation that many customers begged us to fix that lead us to create the conflict feedback features, so it will likely take some very specific problem scenarios for us to work out a fix that accomodates that use case and yours. Any details you can provide on how you would use this feature would help.

Mads
Active Participant

It's not that there are two VIs of the same name in use - it's just that the last time the VIs I want to include (but not recompile) were compiled their subVIs were somewhere else - and I do not want to care because I know I do not really need to.

 

The VI or .llbs I want to include in the installer are run dynamically as plug-ins from the main application. They again call some VIs in the main application, but because they were built earlier/by someone else - those VIs might not be at the same location anymore and this is interpeted as a conflict when they are added to the project - a conflict that you are not allowed to ignore even though everything would run smoothly had only LabVIEW ignored the type of those files.

 

In actual use they will find those VIs just fine because they will be in memory - however if they are included in a project the way they need to be today this will throw conflict errors that you cannot ignore.

 

Now you might say that the proper way of doing this would be to use dynamic calls in the plugins (less conventient)...or better yet - to never do such calls at all (use a communications interface instead) - but to me that seems to be an unnecessarily harsh restriction, especially compared to the level of restrictions LabVIEW currently put on other potensially bad features.

Darren
Proven Zealot
Status changed to: Declined

Any idea that has not received any kudos within a year after posting will be automatically declined. 

DNatt, NI
Mads
Active Participant

Ok...did not know that, should have recruited someone from my team to kudos it thenSmiley Surprised

 

If more people run into this issue and decide to post it as an idea I hereby urge them to ignore the fact that this first post was auto-declinedSmiley Wink

 

 

Darren
Proven Zealot

The auto-decline of zero-kudo ideas is a new policy we've implemented recently. We're hoping that it helps us better focus on the Idea Exchange posts that have more community buy-in. We're going to see how this policy plays out, and potentially expand it to other auto-decline thresholds (< 2 kudos in 2 years, < 5 kudos in 3 years, etc.). We don't have anything set in stone yet except for the current policy.

DNatt, NI
fabric
Active Participant

Darren, seems like you need to automate the auto-decline! 

--
Chris Virgona
Darren
Proven Zealot

There was concern about hundreds of auto-decline emails going out at once if we automated it. So I'm just knocking out a few a day manually.

DNatt, NI
crossrulz
Knight of NI

And at this rate, Darren will be a Knight before Jeff!


GCentral
There are only two ways to tell somebody thanks: Kudos and Marked Solutions
Unofficial Forum Rules and Guidelines
"Not that we are sufficient in ourselves to claim anything as coming from us, but our sufficiency is from God" - 2 Corinthians 3:5
Darren
Proven Zealot

Do Idea Exchange declines count toward my post count? Sweet, I'm gaming the system! 😛

DNatt, NI