Daklu

I agree. All my projects don't contain an end user application, and I have applications that span multiple subprojects, but I never have multiple applications in a single project. At the very least if it was optional it could be used by those who find it useful.

I've considered this as well for my own internal tools. I don't think it opposes the package paradigm, although I would be sure to label it as a 'Palette' package.

Now THAT'S a reason I understand. No, not on purpose anyway. I did say that giving kudos as a response to social pressure renders them worthless, but social pressure can be applied regardless of whether the voting records are public or private. Regarding Twitter, it's my perception (since I'm not a Twitterer) that a stranger subscribing to your feed would likely learn a lot more personal information about you than they would by looking up what posts you kudoed, hence my confusion. I see now that your concern is to provide kudo privacy to those users who want it, not to enforce a blanket privacy policy out of principle. But as I said earlier, this is a 'nice to have' feature that I would use occasionally, not a 'gotta have it now' feature.

I've done NI betas in the past but I really don't have time to be a good beta tester without using the beta version for everyday dev work, which for business reasons doesn't really work out very well. Besides, if I already knew what was coming up I wouldn't be having so much fun trying to figure it out. You make a good point though... I suspect most of the common posters are on the beta and can't post their guesses. In Labview namespacing is determined by the name of the library. For example, the Read method in my Voltmeter class has a fully qualified name of Voltmeter.lvclass:Read.vi. Associating namespace with the filename has all sorts of drawbacks: Reusable code modules must have a filename that is guaranteed to never conflict with another code module name, now and in the future. Nesting libraries to create hierarchical namespaces is impractical in Labview. Loading a single vi in one library will load the entire library tree... not something that leads to efficient programming. There was some discussion about it back in Feb where I explained the problems in more detail to AQ. AQ did say in that thread, "And I think it will provide fodder for contemplation for the next few years. I say that because I don't want you to think the feedback is lost even though nothing may come of it for many years. This would not be the sort of feature that would be rushed into a release." Looks like my guess was a swing and a miss.

Huh? I guess I don't understand how tracking kudos or seeing what forum a member is reading invades privacy. Sure, if we had a 'LAVA Pr0n' forum I might not want someone else to know I was oogling the connector pane of a naked vi, but we don't. (Maybe that's reserved for premium members?) Although I can see how someone would be embarrassed if caught reading the Alfa thread. The decision not to do it doesn't bother me... it just seems like an odd reason for the decision.

Since I'm eagerly awaiting to hear how Labview 2009 (I'll go way out on a limb and assume NI will announce a new release) will extend OOP and I've had no luck prying the information out of crelf or AQ, I thought I'd throw out my guess for public review ridicule. Feel free to chime in with your own guesses--if you guess right I'll reward you with a . (The icon, not the real thing...) I'm also interested in hearing what missing oo feature users think would have the most impact on programming oo applications in Labview. My impact list: 1. ByRef Objects - Yes, you can implement byref behavior using single element queues, but having native support for byref objects would eliminate the (sometimes complex) workarounds needed to get that behavior. Byref objects would be huge! At the same time, I've read that NI has no desire to pursue that as it violates the principle of data-flow and encroaches on the solution Endevo provides. 2. Interfaces - So much of good oop design relies on interfaces I would think (and hope) that NI is figuring out how to do this. This is actually the #1 item on my wish list. I can live without native byref objects. Working around the lack of interfaces is harder. 3. Constructor/Destructors - Another carryover from other languages that could change the fundamental way objects are developed and used, I doubt this is on the roadmap for inclusion. The Decision Behind the Design document clearly outlines why they don't fit the Labview paradigm. (It sure would be nice if LV called destructor methods when the Abort button was clicked.) That said, based on the timeless principle of induction accompanied by a heavy dose of wishful thinking, my prediction for LV2009 OOP new features is... User defined namespaces -- or at least improved namespacing.

Your design sounds very similar to something I posted a couple months ago on Lava 1.0. (Link - The downloads aren't available anymore but I might be able to drum them up if you're really interested.) I'll have to download your code this weekend and study it, but it's nice to see others are trying to figure out how to work around not having native interfaces.

Hah! I knew there was a reason I hadn't signed up for twitter! On the slightly more serious side, I have a real hard time feeling bad for somebody who got skunked while blatently fishing for kudos. And if they then get offended because you didn't vote it up? Puh-leze. That person needs to get out a little more and develop a sense of self-worth that isn't based on an arbitrary rating from strangers. PPPPS: Are you misusing the abbreviation for 'post script'? PPPPPS: Yes, you are. ("Post script script script?") PPPPPPS: Am I a total lamer for calling in the grammar police? P^7S: Yes, I am. This issue really makes me question the point of having kudos in the first place. Kudos are meant to reflect that someone has contributed to the LAVA community--either with humor, by helping others solve problems, sharing tools, etc. The minute social pressure contributes to the decision to give kudos is the minute they become absolutely worthless. Personally, I think it is interesting to be able to trace kudos on the dark side. It gives me another way to find people and topics that match my interests. It also lets me discover that AQ's 29 kudos were all given to him by Darren and a lurker named 'Aristos Notifier.' It's a feature that would be nice to have.

That page shows NI dropping support for Mandrake. Anyone know why? (I don't use it, just curious.)

Being a stereotypical anti-social introvert I'm downright stumped why I would even care that somebody just bought a latte and "OMG! The barista was so rude!" or why anybody else would care that I "Closed 4 bugs today." I signed up solely so I can get up to the minute information on any new stuff announced at NI Week. (Hope nobody gets offended when I drop all their feeds afterwards.) ...and no, I don't have a facebook account either.

I can't respond to 'best practices' as I haven't done a complex plugin architecture, but I have used OGB a lot. If I'm understanding you correctly, you don't have to beat OGB into submission to get it to do your build. (You might have to beat your dev process a bit though...) The problem with OGB is that the 'Exclusions' tab takes precedence over the 'Source VIs' tab. Any VIs you attempt to include on 'Source VIs' that are in the directory tree of a folder you have chosen to exclude will not be included in the build. To solve the problem make sure the directory where you develop your plugins is outside of the directory trees of any of the main sub VIs your plugins use. Then you can simply exclude the directories that contain the sub VIs you are reusing. There are a couple things I can suggest trying: Develop your plugins against distributed code instead of your source code. In other words, install the main application on your dev computer and link to those sub VIs instead of the sub VIs in your development directory. This is what I would do. Your source code tree is likely (and should be) in a completely different location than the install location, making excluding all the reused sub VIs a one step operation. (Exclude the installation directory.) You implied there are lots of sub VIs you are reusing. If the majority of them are not in a parent directory of your Plugins directory you can exclude them by excluding those directories. Then you could go through and individually exclude the few remaining reused VIs that exist in parent directories. [Edit - This addresses how to build your plugins in a way to avoid including the reused sub vis. I'll leave the packaging to someone else.]

Heh heh... maybe you can answer this one... is it something you've seen discussed frequently on Lava? (Or ever discussed on Lava?)

So... under what circumstances is it appropriate?

But you could be. You've just done your consumer research and realized the product doesn't resonate with customers. That's more than 90% of the marketing dweebs experts ever do. Of course, you'd have to check your brain at the door when you get to work...

Hmm... could be I was mixing up my OOP implementations. Go figure. Oh come on... don't leave me hanging like that... Interfaces? Mixins? Multiple inheritance? Friend classes? Hopefully there's more than just the extension onto... uhh... different run time platforms. (You know you want to tell me Chris... it'll just be between me and you... I won't tell a soul.)

FYI, object oriented programming using native Labview classes is typically referred to as "LVOOP." When people say "GOOP" they usually mean Sciware's code generating toolkit, GOOP Developer. Using the accepted terminology will help avoid confusion when you come back with more questions.

Hmph... I guess this means I'll have to finally get off my Luddite arse and sign up for Twitter. ...freaking birds on the internet... Humbug!

I thought it was a railroad spike. Even with your explanation it's still a WTF. The message I get out of it is more along the lines of "scripting broke my heart" or "scripting is dead and I'm heartbroken."

After you download the LVSpeak packages, you need to install them using VI Package Manager before starting Labview. In VIPM, go to File -> Add Package(s) to Package List... Once the LVSpeak packages are listed in VIPM you can install them like any other package.

Just watching a Tim Burton movie is an interesting but bizarre experience... I can't image being in one.

I didn't mean to imply that you were. I made that comment mainly for newish LV users who might be wandering down the same path I did. In the past I've wondered a bit about how to deal with the situation you're describing. The best solution I've come up with is to distribute the base widget code to two locations: user.lib for using it in vis directly and another directory that serves as a source for copying. I've also considered (but never experimented with) setting up file or directory links (forget what they're called) on the os level and having the vis in user.lib simply wrap the functions in the other directory. Unfortunately all these violate your original assumption so I didn't mention them. SciWare's solution is definitely much more promising than anything I came up with. Kudos!

I have encountered that before, but it was because I wasn't properly separating source code and distribution code. (Using user.lib as a source code dev directory != good idea.) Once I adopted better project organization practices the problem went away.

Pure speculation here... My guess is that in memory, the computer not only needs to know the value of the 32 bits, but it needs to know the type of data it is as well. It's been eons since I've done any C/C++ programming, but I believe changing the data type in place would mess up the pointers. They would think they are still pointing to a sgl but are in fact pointing to an int. ('New math' takes on a whole new meaning!) Therefore, type casting will always create a new buffer with a new pointer (and new pointer type) pointing to it.

Yes on both counts. (I need to figure out a way to collect and organize all the tidbits of information I gather.)

Are you sure about that? I'm sure I've read that putting input controls inside a case statement prevents LV from making certain compiler optimizations. I can't find the reference at the moment though. Meh... 'Use Default if Unwired'