soupy

Short answer is no. you can't easily modify dependency locations. Longer answer is yes. you can modify environment search paths to point to the new target and delete the old target files to force re-linking, but this is really the hard way and it's going to get you into re-linking trouble/hell. Correct answer is that you're not using vi packages correctly. The code that goes into a VI package should be able to stand on its own. You should be able to debug/test/validate all VI package source code before you build it into a package. Think of a VI package as formally released reusable source code. If you feel the need to constantly switch between built packages and source code, then you're not adequately validating/testing before building the package. Hope this helps.

agreed. this is sort of a hack. i wouldn't be surprised if this functionality broke in future labview versions. I'd suggest not ignoring all errors coming out of this so you'll know if something changed. instead, ignore only error 1 coming out of the close VI

yeah, close functions should always execute. you wouldn't want to have a shutdown error and leave thing allocated. you should keep this in mind when making your own tools. my teams has formalized our style to always call this VI "destroy.vi". it should have an 'X' on the icon and should always execute even if errors are passed in and should pass through incoming errors. This follows the NI paradigm. We believe that the more our code resembles NI code style & interface, the more likely it will get reused by ourselves and others (less learning curve).

here ya go. this only works if your cluster only contains user events but it'll close all data types. if your cluster needs to hold more than user events, you could probably get around things by storing user events in a sub-cluster.

one of my guys just got his recently. it took a month the get the test results back. I hope you have enough time to take the exam and make the summit.

cross posted here https://decibel.ni.com/content/message/64013

i'm doing something, but i don't know what to call it. is this an accepted design pattern? background: i have a configuration class for my application the configuration class contains paths to external (excel) files you must parse out the external files and put their information back into the configuration class. i refer to this step as "parsing" i'm passing the parsed configuration class over the network to an RT system, so my configuration class can't have any dependencies to non-RT stuff (e.g. Excel (ActiveX)) everything is dynamic dispatch so i can get some reuse out of this design pattern explanation:in this example, i have an array of configuration classes all parsing functions are in methods of a "parser" class (chain link wire) there is one parser class for each configuration class the configuration class knows the path to the parser class So, does anyone have an official name for this sort of thing? I've been referring it as "side loading". Anyone have any lessons learned on this approach? Am i running head first into any traps?

i don't think that we currently use more than one ES per BD, If we do, the secondary ES is in a subVI. Will things be broken if the subVI is inlined? (I assume it would) I'm quite concerned that this breaks existing code. The LV upgrade eval process is typically riddled with surprises and this just adds another pothole. Especially since the only way to fix this is to overhaul your application architecture which isn't exactly an easy change.

spacex is donating an "occupy mars" t-shirt and a model rocket

ah, that's the term i was looking for. yup. makes total sense now. better to have obscure names than hard to find bugs. thanks!

so everyone knows that a parent and child class cannot have VIs of the same name unless they are dynamic dispatch. The compile will fail if you violate this. so, my question is, why is this restricted? Is there a technical reason that this can't be done? I ask this because i am working on a set of configuration file classes that are written directly to file. To deal with non-trivial permutations, i'm following the recommendations here (http://thinkinging.com/2007/04/14/supporting-multiple-versions-of-a-file-format/) and including a revision number in every class, subclass and child class. Because of the above naming limitation, i'm going to have to dance around naming conflicts since every class will be responsible for upgrading itself to its latest revision and will have similar functions. (e.g. ideally every class could have a function called Upgrade1To2.vi to upgrade from revision 1 -->2) additionally, i'm pushing our team to use standard file naming terms and increase the modularity of our code via private methods, so I'm afraid that we're going to run into this issue more and more often. I understand that it could be non-obvious that you aren't dispatching to the child method. Maybe you could explicitly acknowledge this? Maybe it could be allowed if it were made private since private methods cannot be dispatched? You think this is good enough for the idea exchange? Anyone else find this useful?

I sent your articles to my colleagues in an email titled "egoless programming" and they thought it was a joke. I've got a lot of work to do here...

this is great! i'll be testing this immediately! I'm guessing that this will eventually be released publicly once your release cycle comes around?

i'm working on moving my large library of reuse code (2300+ VIs) into VI packages. because of the scale of my code base, i'm forced to migrate over a span of time (measured in months). This is leaving me open to configuration issues (as a consequence of using configuration management ). does anyone have any advice in this area? my issue is described in much more detail here http://forums.jki.net/topic/2103-rename-vi-dependencies i think that most of my issues can be solved by implementing this http://ideas.jki.net/topic/167846-rename-dependencies-without-renaming-package-files/ Thanks!

putting in a blank password make the "password type" switch back to "none" it may work if they add "locked (no password)" to the "Password type" dropdown