crelf

Thanks Greg - that was the definitive answer I was looking for.

One thing that I've wanted for a long long time in LabVIEW is Native Support for Dynamic Palettes. I'd really appreciate it personally if everyone took a minute to read (and possibly even vote for) David_L's idea on the idea exchange here. If you're interested, take a look at jgcode's post on JKI's VIPM Idea Exchange here too.

Yes, that's right. Unless I'm missing something with your explanation (which is entirely probable), there's a couple of issues with what you're saying: there's no parent/child heirachy here - in fact, the issue isn't anything to do with LVOOP at all - it's to do with any dependancies with the same name. The more important issue is that I already tried what you're talking about, and it doesn't work: dependancies with the same name cause the Caller to see the Callee as broken.

The dependancy isn't *supposed* to be different - but it might be. Is this statement true? If so, you've answered my question. What do you mean by "saved in the same version"? So you've got to my reall issue here: the point of the exercise is *not* not to avoid sharing - it's to allow my developers to create their own plugins using VIs from any of our internal reuse libraries without having to worry about if I used any of the same reuse VIs in the Caller (I *almost* achevied this by renaming in my caller). I *think* you're telling me that what I want to do can't be done - but I;m not completely sure.

You're absolutely right - I should have called it "Namechanged" instead of "Namespaced", or the like. Maybe I'm misunderstanding the options you list, but I don't see a solution there. The issue is two fold: I can't load a plugin that has a dependancy that has the same name as one of the application's dependancy (the plugin is reported as broken) - that's why I have to namechange one of them. Your solutions seem to have the dependancies in a shared resource outside the Caller and Callee - won't this have the same issue? Anyone on my team. Yes. Yes. I don't understnad this question - are you asking for a list of them? Being able to load the Caller dynamically from the Caller application.

I'm using a feature in one of our core products that's unlreleased: only because I can't do what I need to in any other way. Thankfully it works wonderfully (and I hope it'll become a released feature in the near future). Without it, I'd be screwed. You could call that buired treasure - I sure would I'd be inclined to agree with you iff the feature could be rewritten in supported features and I had the money to pay for you to do it. In my example above, I can't do it with supported features, and even if I could, it might take me 10x time to do it. As long as my customer is aware that I'm using unsupported features, they can choose to spend their money either way. That said, I work for an NI Platinum Alliance Partner, and the support we get from NI is, well, platinum - even on unreleased features.

Sure, but remember that users with all levels of LabVIEW knowledge might read your post, and I'd rather it was more clear is all.

That's not always true - a subVI can show its panel.

Oh yeah - we went to The Iron Works - it was awesome! Another reason it was awesome!

Yes, that's right.

PS: I was able to implement a solution in a way that's outside the context of this discussion, although I'd still like to see a solutio to this question.

Nope - one executable that calls a vi. That's really quite interesting - I've never had that issue. Have you got an example, or have you reported that to NI? I guess it could, but I'd rather not have a third component at all, if possible. Maybe take a look at the code when you get a chance: that should make everything much more clear. Thanks for the reply 0_o, but I don't think it quite applies in my situation. I'd apprecaite it if you could take a look at the code I uploaded if you get a few minutes - : that should make everything much more clear.

Are you suggesting having a built Caller exe, a Callee vi, and a source distribution with all the shared stuff in the middle? That sounds horrible, and unmanagable. In what way? (I"m actually distributing the Callee and its dependancies in a PPL, but that's beside the point in this scenario). Can you expand on that? I've had a few issues, but mostly due to my own misunderstandings on how they work. Now that I've got a good working knowledge of them, I think they fill a good niche.

...but it's challenging to be a *good* software architect: http://t.co/DNqxMny

I had a difficult time trying to decide which category to put this in - it's a tricky one, so here goes: I've got a simple application: There's a "Caller" (a built application that the user opens) and a "Callee" VI on disk that the framework opens - nothing too difficult about that so far. The Caller has an object in it where I set some stuff, then I want to pass the object to the Callee through it's connector pane: Then, when called, the Callee displays the stuff to the user: When I run this in the development environment, it works fine. When I build it, it works fine too. When I build the Caller application, if I include dependancies (read: subVIs) in the Caller and Callee that are the same (read: have the same name), calling the Callee from the built Caller won't work: it errors out with the Callee being "broken" (it's not really broken, there's just a namespace collision, so it refuses to load it). And I'm cool with that - the solution is to namespace the dependancies in the build, which is fine. So "what's the problem?!?" I hear you ask! All this worked great until I started trying to pass an object from the Caller to the Calle through the connector pane. (I think) Since the class is namespaced differently in the built Caller to the non-built Callee, I get ...which, as you can imagine, sucks. I totally understand why it's happeneing, and even agree that this is the way it should be, but that doesn't help me complete my application. I want to pass an object between a namespaced-exe Caller and a VI Callee - I don't want to deconvolute the object's data to an intermediary (like a variant or string I guess) and rebuild it to a copy of the object on the other side (unless I really have to - but I can't think of a generic way to do it that I like right now). Does anyone have any bright ideas? Hopefully I'm missing something easy, right? I've included an example below. //Crossposted to NI Discussion Forums. Passing Objects between name-spaced application instances.zip

Take is easy people - turn down the flaming please. If you have an issue with another user's tone, it's against forum rules to comment about it in threads: report it to a moderator instead.

I agree - I've used Eurotherm a lot: they're a quality product, and are easy to integrate with.

V I Engineering, Inc. is donating 2 x Microsoft Kinects for Windows, compatible with LabVIEW! Upgrade your test systems to a virtually real* HMI! Track gestures and objects in the room and control your virtual world through the power of Kinect and LabVIEW (you can find out more about communicating with the Microsoft Kinect here and here, and you can download drivers here). *This door prize will not make you look like Tom Cruise. Unless, of course, you already look like Tom Cruise. In that case, sure, let's say that this door prize will make you look like Tom Cruise. Yeah, that sounds pretty good - put that in post. Wait, are you writing that last bit down? No, the "...let's say that this door prize will make you look like Tom Cruise" bit. No, don't put that part in the post - I don't want anyone to think we're actually promissing to make them look like Tom Cruise. I mean, c'mon, they'll never fall for that. Will they? You know what, maybe you're right - put it in there and let's see if anyone falls for it. Wait, why are you still writing?