jgcode

Yeah, except the part about me not remembering a discussion from three days ago.

Thats alright, I just thought I was going crazy

I created this example project to explore the behavior and there are still things going on I'm not understanding. I get the impression that each individual decision makes sense but I find the overall behavior rather confusing.

Great post. I will have to spend some more time looking at what you have come up with before I can comment.

Thanks for the reply, that helps.

I have found a page on ni.com that shows how to switch menus but the demo is for 2009 and I only have 8.2. I don't suppose anyone could save out an old version for me please? The link is:

http://decibel.ni.com/content/docs/DOC-9341

Here you go mate:

Select_RTM.zip

[LabVIEW 8.2.1]

Hi there,

I'm trying to figure out how to let my sub-panel have access to the parent vi's menu. Hi main vi will be a shell pretty much and then the user will select which DAQ app they want to use on that occasion. That DAQ vi will then be loaded into a sub panel and away we go. However, they sub panel will need to take inputs from the menu, and set it's own applicable menu items.

Can anyone help please? I'll keep looking myself and post back if I figure it out.

Thanks,

Martin

Hi Martin

There is a Current VI's Menubar primitive available in the Functions Palette >> Programming >> Dialog and User Interface >> Menu subpalette.

This is a reference to the menu but you will have to pass it down from the Main VI into your subpanel VIs (or use a variable etc...) as it is not exposed through VI Server.

Cheers

JG

This is now scheduled for April 7.

For those who attended NI Week 2009, this will be mostly the same material that I presented in my advanced OO session at that point.

Sweet!

I know you said your team was flat out so thanks very much kudos for putting this on.

Will you be presenting?

And from AQ a few days ago...

Sweet, I knew I had quickly read it somewhere, I thought it was on the darkside.

All good news

I am under the opinion that all VIs in a class get loaded into memory, but not all VIs in a library do.

Can someone confirm this please

From the dark side:

Just to clarify, LabVIEW loads all members of an LV class when a class or a member VI is loaded. LabVIEW does NOT load all members of a regular project library when the library loads.

George M

National Instruments

But I have been guilty myself sometimes...

Haven't we all...

The other issue with files being locked by LabVIEW that another application opened I'm flabbergasted. Never saw that happen so far.

Well LabVIEW locked files that where in my Recycle Bin today... weird.

Well, LabVIEW has a LOT of error information and much of it has gotten fairly descriptive over time. So part of the problem may actually be the amount of error information that is already there and that makes identifying areas that can be improved a bit hard. Also maintenance of all that information has to be a real nightmare by now.

Well... "Development Environment is required to fix error" and "Dynamically launched VI cannot run because it is broken" (or whatever) are cases where LabVIEW is not descriptive enough in my book.

Being the LabVIEW enthusiasts as we are, we usually have many versions installed and can down save. I have 8 at the moment, do I hear 9?

I have 5. You win.

Those Xs also appear when the library is licensed and you don't have the license installed. ... but if you can drop them successfully, then that obviously isn't the problem. No idea what it could be.

Ok, in the palette I just noticed that the Owning Library is pointing to the .lvclass file - to which the VI belongs - but the class is actually wrapped in a library (.lvlib).

Could this be an issue?

Is it a bug?

Also when I view the palette through Advanced>>Edit Palette Set there are no red crosses.

I will try scripting the palette with the new Mnu File API and setting the Owning Library to the .lvlib file and see what happens.

Well, I suggest you readjust your thinksing . It was around in 7.0.

I will need to. I didn't know that feature went back that far.

I try not to use 7 as much as I can, unless I have to program src for a client that won't upgrade... hmmm that topic sounds familiar....

I don't remember that discussion.

Sorry, I thought you mentioned it on an NI forum. It must have been someone else.

Does that mean all the classes in a library (and all class members) get loaded, or just the class members of the one class that is used (assuming multiple classes in a library?)

I am under the opinion that all VIs in a class get loaded into memory, but not all VIs in a library do.

Can someone confirm this please (AQ )???

I no longer have a general reuse library for simplish operations, primarily because the benefit I got from them didn't justify the overhead of maintaining them in a reuse library, but also because I'm trying to control the dependencies my applications and reuse code has on external modules. I do have a bunch of utility VIs I can use, but I'll either copy the vi and add it to the application code or occasionally I'll copy the code directly to my target vi. My reuse code modules target relatively large chunks of functionality, such as message handling, various kinds of data structures, etc.

If I had released a single class as a reusable code module, and later wanted to extend the functionality with additional classes, I would create a new code module with the original class and the additional classes packaged in a lvlib. The original class and the class in the lvlib can exist in memory at the same time, so the calling code doesn't break. If I want to upgrade source code to the new library, then yes, code breaks and I have to fix it manually. However, so far the only single-class reusable code modules I have are instrument drivers and I haven't encountered a situation where I would add additional classes to them. I have created mock instrument drivers by overriding the functioning methods with empty methods in a derived child class, but I consider this application test code rather reuse code.

Great post, thx, its cool to hear someone else's approach to reuse.

Do you distribute your reuse code in packages (e.g. .ogp or vip) to your developers?

The questions are a little ambiguous. I'm not sure if you're referring to a built application or application source code. Currently all my reuse modules are intended to be reused during dev-time, not run-time, so I'll address it from that perspective.

I change major version numbers (and hence the module filename) only when backwards compatibility is broken, so any compatible updates are automatically included in the application source code the next time I open that project. Since new versions are incompatible by definition, I don't want applications to automatically use the new version. The application still loads the previous version of the library so it is not broken.

Not so much in the same application, though there's no reason I know of that it would inherently break code. It's more so I don't have to fiddle around with making sure I have the right version installed for a given project. I can simply have them all on my dev computer at the same time.

Sorry about the ambiguity, I was interested to know if you updated the reuse module, and you wanted you application code to link to this new version, how would it be handled automatically (which you have answered).

The more important feature (for me) is the ability to set the scope for specific classes within the library. I can have all sorts of utility and worker classes in the library that I've scoped as private and aren't part of the library's public api. This ability alone is a huge help in keeping my code organized and maintainable.

I am purely looking at the benefits for namespacing, so I meant more beneficial when compared to a single class... ...but obviously access scope is the major plus if that is required, for a particular release.

Does the context window mention anything?

Ton

No, nothing from my documentation.

The Control Palette is fine (no crosses) and they are in the same library and have the same scope (public) as the functions???

I don't see the use of a class inside an lvlib, a class is a special kind of library, so it's not really usefull.

You can namespace the class by wrapping it in a library.

This is more beneficial if you have multiple class (in one distribution) that you want to rename for distribution.

I include the library right in source code rather than adding the code to a library during the build. Doing it in source helps me maintain the separation (both in code and in my head) between the library functionality and the library api.

Me too, but I rename the library in the distribution process as to avoid a clash with the source - e.g. after it has been distributed to <vi.lib>.

This way I can control the member scopes

I only generate a new library if I want to wrap up support VIs so the release does not have those dependencies (e.g. from OpenG, my reuse library etc..).

This is a great way to do it for toolkits.

However, I have finally taken AQ's advice and starting using lvlibs to organize my code into modules, and despite the inconvenience of writing more wrapper methods I think it is worth it. It definitely helps me maintain a layered application structure and limit interdependencies.

Is this your application code or reusable code?

I have been using .lvlibs a lot lately in my application code, and it has been working out very nicely.

I now what to see where these fit with respect to reuse.

I was of the same opinion as you - that .lvlib items get loaded into memory as a group - but AQ has pointed out that this only relates to classes, which I did not know and thats why I shied away from them in the past for reuse.

However, I use VIPM and its namespacing for my general reuse library (string, boolean etc..), but at the moment I handle toolkits and classes myself (as there is no need to rename the member VIs).

I have been renaming the .lvclass file during the build, but in order to make my namespacing more unique and am looking at the best way to distribute those - rename .lvclass or use a .lvlib wrapper instead.

If I was distributing a single class, I wouldn't bother putting it in a library unless I expected to add more classes to it in the near future.

But then, if you did expand the source release in the far future by adding another class (for functionality or to release an inherited class), the original class would name be namespaced differently and your calling code would break?

Therefore, I am considering doing it for even single class released.

Plus I don't have to rename the class then - so it is no more or less work for me.

Add multiple classes in a library is great, as I only have to rename the library during the build, not each .lvclass file - so in that case its less work.

Short answer:

Descriptive library filename appended with major version number.

EventManagerLibrary__v1.lvlib

MessageLibrary__v2.lvlib

So how does your application code get updated automatically when you release a new version of your reuseable class?

If the reuse library name changes between releases, then your application code would break?

Cheers

JG

That happens when the scope of the palette vis does not allow the active vi window to use them. If you open a vi that does have scope to use them, the x's will go away.

Thx Daklu

All the VIs in the palette are public VIs of a class that is wrapped inside a library and the class is public to the library.

Therefore any VI I choose should be able to access them, and when I drop them on the BD, they all work fine!

Weird!?!

Howdy!

As a developer distributing classes, what type of namespacing do you do/use?

I have been renaming the class during the source distribution (NI app builder).

But I have been thinking about using libraries (.lvlib's) a bit lately

Somewhere after 8.2, and definitely in 2009 you can add the source to a lvlib during a build

This seems a handy way of renaming the entire class hierarchy all in one go.

Any which way better?

Cheers

JG

Such as 7.0?

No, 8.5+ methinks.

What's the best way to access the same object from parallel loops? And I mean THE same object not copies of the same object, because so far this is the only thing I've achieved, so updates from one loop do not make it into the other.

Thanks in advance, Mike

Hi Mike

You have a bunch of options to create by reference (ByRef) objects all with their pros and cons, here are some...

• Use LVOOP with Data Value References and the In Place Element (IPE) (new in 2009)
  
• Create a Single Element Queue (SEQ) and create your own ByRef API
  
• Use a third party tool such as Endevo GOOP, Sciware etc...
  

Does anyone know why my icons have crosses in the bottom left hand corner?

They seem to function ok, and I can drag and drop them on the BD?

I made the palette manually.

Cheers

JG

For them who doesn't not it. There is a build function in LabVIEW to swap two wires connected to any 2 input function.

Just use the wire tool and press Ctrl+click.

//Mikael

A quick note: this is only supported in the more later versions of LabVIEW.

 

From here.  Is yours different? 

Looks like this version supports the Select and Coerce primitives too!

And (from the pic) it looks like you can swap a terminal if no other terminal is yet connected.

Cool, nice job

For the record, and as an aside, NI isn't forcing anyone to upgrade their verson of LabVIEW every year.

What kind of LabVIEW enthusiasts would we be if we didn't upgrade to the latest and greatest!

isn't 2009 SP1 the equivalent of 8.0 -> 8.2

FWIW, I think 2009 SP1 is the equivalent of 8.2 -> 8.2.1

I think the thing that bothers me about that is the lack of backward compatibility (i.e. I can't open 2009 code in 8.6 (yes, I know I can save back one version, but that's not the point)).

One of our main products is still using LV7.1. When we sell a system, we often include a LV license. Then, if we need to upgrade the system, tweak things, add features, or whatever, the system already has a LV license that we can install and use. If we upgrade to a newer version of LV, then we can no longer use our latest and greatest code on those older systems without upgrading their LV also.

I think this whole "forced upgrade" vs. patch or minor release approach would sit better with me if I could easily pass code back and forth between versions, with newer structures, functions, whatever showing up as broken icons (kind of like missing subvi's) if they aren't common to both the newer and older versions.

This is something that doesn't sit well with me as well, dealing with customers who require source and having to support their LV update schedule. And it gets worse with hardware's software (cFP, cRIO etc...) that needs to be updated too.

Using MS to compare against, Office 2007 superseded Office 2003 so thats ~4yrs between versions. I like the idea that 2009 is interchangeable with 2009 SP1 code (as is e.g. 8.6 and 8.6.1). Maybe it would better if this was the case for longer i.e. all releases for 4 years will be guaranteed to be compatible?

However, given the new yearly schedule I think not.