crelf

It took me a little while to understand that "namespaced" meant using the build option "Apply prefix to all contained items" in "Source File Settings" for dependencies in the build spec. Once I made that connection everything makes sense. This isn't really namespacing. This is changing the name of every dependency.

You're absolutely right - I should have called it "Namechanged" instead of "Namespaced", or the like.

So after the build Caller.vi references a class named "namespace.Shared Class.lvclass". Since Callee.vi didn't go through the build, it references the class "Shared Class.lvclass". A VI that has a single input of type "Shared Class.lvclass" is not going to match a strict VI reference with a single input of type "namespace.Shared Class.lvclass" so the open of the reference fails. If you are going to rename the class during the build, then all plugins must be rebuilt against the renamed version... There are a few other options though...

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?

To decide which approach to take, I'd want to know what you are really trying to get out of using a plugin approach. Who is going to be building the plugins?

Anyone on my team.

Are the plugins supposed to be able to update independently of the application?

Yes.

Should the application be able to update without invalidating the plugins?

Yes.

What VIs/classes used in the application should be able to be referenced from the plugins?

I don't understnad this question - are you asking for a list of them?

What were you trying to accomplish with the name prefixing option?

Being able to load the Caller dynamically from the Caller application.

...keep in mind that unreleased features are not like finding buried treasure.

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

...if I were your customer and found that you used an unreleased feature in code you supplied, I'd ask you to rewrite it using supported features...

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.

Well, yes, obviously, but is that a concern here? Just because something is possible doesn't mean it's relevant in this case.

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.

Isn't that what you were after? If the subVI is running on its own as a "regular" subVI then its front panel would not be open.

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

Usually on Thursday night we meet in the loby of the Hilton and decide what to do then.

...

the year before that it was Bar-B-Que and then we went to see the Bats flying off the bridge.

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

Any and everyone is invited and Talking Shop is mandatory.

Another reason it was awesome!

My first impression of what you're describing is you're creating a plugin, or at least something very similar.

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.

I'm interpreting the situation as you have two executables which you want to operate independent of one another...

Nope - one executable that calls a vi.

As for packed libraries, all I can say is twice I've tried to use them in a large project of mine, and twice I've had to revert because the IDE became simply unusable (slow and unstable).

That's really quite interesting - I've never had that issue. Have you got an example, or have you reported that to NI?

My thought was this third component could in theory be a PPL.

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.

I'm short on time and I didn't even have time to open your example, thus, I hope I understood your question good enough.

I think I'm doing about the same thing and yet I don't have to play with any namespaces and it works just fine.

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.

Sounds to me like this is the sort of thing source distributions were made for. If I recall you can still strip diagrams despite them being called "source" if that's a concern. Put whatever classes are used in the exposed APIs into the distribution and exclude the types from each of your application build specifications.

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.

Packed libraries in theory would work too...

In what way? (I"m actually distributing the Callee and its dependancies in a PPL, but that's beside the point in this scenario).

I'm personally not even close to trusting (PPLs) given the headaches they've caused me the few times I tried using them.

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.

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

Error 1031 occurred at Open VI Reference in Caller.vi

Possible reason(s):

LabVIEW: VI Reference type does not match VI connector pane.

VI Path: C:\Users\christopher_relf\Desktop\Passing Objects between name-spaced application instances\Callee\Code\Callee.vi

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

Well. I highly recommend Eurotherm controllers and they have LabVIEW drivers.

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

I didn't know the fun wrapped up mid-day Thursday, so my return flight isn't until Friday evening.

A lot of ppl hang around until Friday morning, so Thursday night won't be wasted. The evening festivies are usually pretty tied up the rest of the week (Sun=Gingerman,Mon=AllianceParty/6th Street,Tue=LAVA/OpenG BBQ,Wed=Conference Party), so Thursday is more freeform.

I suggest you follow @lavag (if you're in to that sort of thing) as a bunch of us tweet to that account about things going on outside the conference.

I strongly suspect a semi-competant 8th grader could out-argue me in any discussion of grammatical construction. My knowledge is exhausted just beyond noun, verb, and adverb.

I'm certianly not a lingustic expert either, and when I know I can't speak with authority, I refer to someone who can, hence my dictionary quote for the definition of "sentence". Unless we limit the debate to the learned's definitions as opposed to our own limited understanding of what we think it might be (or, more possibly, what we would like it to be), I think it's futile.

Just for some off-topic fun, I'd like to point out that this has been attempted, sort of.

Ahhh Victor, thanks for the afternoon laugh!

I guess the question is: Is there a way to find sequence caller from within the TestStand project?

Yes, but only during runtime

RunState.Caller.RunState.SequenceFile.Path

Punctuation is an artifact of written communication. It does not exist in verbal communication. As our conversation was verbal and not written, there is no punctuation to be included as part of the sentence.

That's like saying that a spoken conversation doesn't have any words or sentances either - just sounds. Except that both parties understand the communication because they have a common frame of reference of, um, a structured lanuguage of words in sentences.

Anyway, as we're debating definitions, we should have references (emphasis added). From http://dictionary.re...browse/sentence :

sen·tence

noun

1.

Grammar . a grammatical unit of one or more words that expresses an independent statement, question, request, command, exclamation, etc., and that typically has a subject as well as a predicate, as in John is here. or Is John here? In print or writing, a sentence typically begins with a capital letter and ends with appropriate punctuation; in speech it displays recognizable, communicative intonation patterns and is often marked by preceding and following pauses.

Even if you argue that punctuation doesn't change a sentence (which it does), your example changed the predicate, which is half of the makeup of the sentence in question.

I'm not NI anymore. I wish the mods would fix that for me...

All you needed to do was ask, but next time you need something moderated, try contacting the mods directly rather than alluding to something in a thread - we don't read them all.

Ok, that sounds super wierd. Can you strip down the code and upload a chunk that demonstrates the issue? ie: an example with read/write methods that access your data.

Punctuation is part of the sentance, therefore your assertion is incorrect.

More importantly: what was your side of the wager? ie: what did you promise to do/not do should you be unable to prove?

This is a good read: http://www.ni.com/white-paper/6316/en, then maybe read this: http://lavag.org/topic/14548-class-mutation-history

"the sort of exercise that drives programmers to contemplate text."

whoa Whoa WHOA! That's crazy talk right there!

Woot!

Shameless plug: Image Acquisition and Processing with LabVIEW.