crelf

Hi Irene, I wouldn't worry to much about you reply - we all get frustrated when we think that someone is trying to take advantage of us, and I agree with Jim's earlier comments about posting your homework on a professional forum seeking answers to the complete system from professionals is akin to cheating. As has already been said, if the student takes the time to try to understand the question, and at least makes an attempt at it (and demonstrates that), then no worries, but cut-and-paste a whole class assignment? That's asking for wrath PS: I think Micheal's post :thumbup: is in excess of what the original poster could expect (although it'd be nice if they came back with at leat a thankyou... :thumbdown: )

The story of Ctrl+Alt+Del...

Just don't touch his lobes!

I don't see any way to do it from LabVIEW, although the project file is just an XML file (try opening one up in a text editor), so you could certainly dynamically create one using LabVIEW itself.

...as was 5.1.1 - probably my favorite two versions.

Thanks for your help Rolf :thumbup: I'll check it out!

Is that true for a built application? I was under the impression that even dynamically called VIs had to be called as subVIs somewhere (like you said - in an area that is never called) in the built application. The way I get around this is to include a "tree" VI outside of the exe (but still part of the build) that includes all of the dynamically called VIs on it's BD - this means that if I need to update the system later and add new dynamically called VIs (ie: plugins), then I can overwrite the tree VI and include my new dynamically called VIs and they will load...

The word from NI is that they had it up on thier site to do a little testing and wanted to make sure that all the links were in place before they announced it - the plan was to generally announce it today (thursday the 9th of March) - Mike just found it on NI's site first

Try a normal LabVIEW mass compile on those VIs directly - you may find that they don't compile using that method either. I had the same problem (but with some personal VIs) and it turned out that they had insane objects in them.

Damn you Jim Kring! Now I can't tell my boss that I couldn't do any work for a whole day because my 8.0 was mass compiling to 8.0.1!

Let me be the first to say: Wow! Great idea and excellent execution! I really appreciate this little utility (as will the rest of my engineers who will be surely using it over the comming weeks to get their own 8.0's to 8.0.1. Funny that NI never thought of doing it this way... Other than the processor usage going to 100% when it's listing the VIs to compile at the start (this can be fixed with a 0ms wait in the recursive file list vi), this has saved me about a day - thanks sooooo much! My 8.0 -> 8.0.1 mass compile time went from more than 7.5 hours (I actually cancelled it, and it was only 2/3 of the way through), down to 36 minutes :laugh: I seriously owe you a :beer: at NI-Week in August - and I suggest that anyone else using this little marvel should think about putting your name down to buy Jim a :beer: as well!

I gotta admit, since I've been waiting for my 8.0.1 to mass compile, I've made more posts at LAVA today than every before!

Did that yesterday - went skiing ...I suppose I could go surfing if I, say, lived right on the beach... Sure does, but the mass compile is loading/unloading/loading/unloading/loading/unloading VIs from/to disk, and it's just thrashing away (yep: it's still bloody going - up to 6 1/2 hours now )

This mass compile is ridiculous - I'm already over 5 1/2 hours (and I was hoping to do some work today - not with an unresponsive PC).

I used to be a farily active member of NI's discussion forums, but I was getting soooo swamped with trivial questions from people that either hadn't attempted to read the manual or work on it themselves. I don't mind newbies (university students or otherwise) asking questions on components of their systems, especially when it's obvious that they've tried to make it work but either just need help with that last 10% of the solution, or are after a better way of sompleting what they've already implemented. I've since pretty-much abandoned NI's discussion forums (I justify it to myself by saying that not only are there plenty of knowledgable folks on the forum that are simply itching to help out these people, but also because I've only got a small finite amount of time each day to devote to them - sure enough, I've got to earn a wage too and I'm pretty pressed for time as it is. I'd love to spend more time helping out at the NI forums, but I just can't). So, I made the decison to switch to LAVA - partly because of the "Advanced" part of the LAVA acronym. I can't tell you how much I appreciate the high SNR here at LAVA. It's true - I'm elitist: I don't want to read posts from people that want to know how to put a control on their front panels - that's what manuals and NI's AEs are for on the NI forums. To that end, I partly agree with Michael Ashe's idea of a notice pinned to redirect those wanting help with shool work - except that I'd redirect that link over to NI's discussion forums where there are heaps of people just bursting to help with those sort of questions. In my company, I've created an internal list of LabVIEW related links to help out my developers, and each of those links has a description. It's sort of my personal thoughts on various resources - here's an excerpt: NI Discussion Forums These are the NI discussion forums where you can ask all sorts of questions relating to all NI products, as well as other engineering based domains. This forum can get a little overwhelming as it serves the very simple to the extremely advanced. Info-LabVIEW Mailing List This is a sentimental favorite of mine - it's an email-based list server where you can ask questions and get answers from LabVIEW peers. It's not NI based, so it's not censored (eg: last year a fairly heated discussion broke out regarding NI licensing policies). It's available in a daily digest which is pretty convenient. You can search previous posts using http://www.searchview.net (you can go waaaaaay back and see old posts from me when I didn't know a polymorphic selector from an object class browser...) LAVA User Group This is where I spend most of my time: LAVA (LabVIEW Advanced Virtual Architects), which is a user forum supported by the absolute best of the best - these are the guys who can do just about anything. That said, as the name suggests, it's an ADVANCED group, so posting here can easily irritate the Gods and invite a pox on your family name for all eternity. Seriously though, a good place to start is to read old posts and maybe lurking for a while (a few months at least) before diving into this one. Also: this site has an extremely important resource for those starting out in LabVIEW: the unofficial LabVIEW FAQ! It's a great place to find all those odd tidbits and an important place to check out after you've been programming for a wee while. :!: it'd be great if new users we forced to lurk (limited access to posting) for a few months after they joined unless they could provide proof that they know what they are talking about... Awww, maybe I'm being too elitist now... Either way, I'd still like some method of pushing newbies over to NI's forums to start with - I truly beleive that they'll get better support over there, and then come back here once they've progressed and are taking LabVIEW seriously. :question: Otherwise, LAVA will just become just like NI's forum, and we don't really want that, do we?

That's quite a novel approach - well done! As long as it's well documented so the next developer that works on it isn't sctaching his/her head, then it sounds just fine to me

I had posted to this thread a few days ago, but it doesn't look like it made it Are you able to add a sample image for us to look at? It might make it easier for us to provide suggestions...

I know that I'm getting away from LabVIEW, but I was hoping to benefit from the expertise of the list - surely someone here has tried to do this before... Using USER32.DLL I've been able to change the window's mode to non-floating and position it where I want it on the screen, but I've had limited sucess with the size of the window. Using MoveWindow, I'm using the following prototype: long MoveWindow(unsigned long hWnd, long Left, long Top, long Width, long Height, unsigned long Flags); Sure enough, it moves the window and it even sets the width correctly, but the hieght doesn't respond to anything I set it to (it actually just draws the bottom of the window off-screen). Any ideas?

I think that was the original original logo...

I sure can't wear it, but here's my earliest NI relic:

Thanks everyone - the double reference solution works perfectly: Also, I don't need to use the CBRN as each plugin runs autonomously - no interaction via the connector pane, but a couple of functional global queues...

Ahhhhh - of course it does! Thanks for your help! I'm not useing the CBRN because I need the plugin to run in parallel to the rest of the app - if I use the CBRN then I need to wait until it's completed exectuion for my main to keep running (don't I?)

I know that I'm coming in really late on this, but my background image is obviously a programmer's - it's not very imaginative, but it sure is functional: Note: if you're going to use it, ake sure you remeber to set it a "center", and not "stretch"

Thanks for the explination - I agree: I've had the same issue in the past, but the problem that I'm currently having happens in the development environment - I haven't even tried it as a built exe yet I know that I I don't need to use a specifier to just run a VI dynamically, but I'm using it this way so the error cluster allows me to determine if the opened VI is of the correct type to use as a plug in.

I'd thought of that, but it's not as trivial as it sounds. I'd need to take several things into account: * font size, as you mentioned * what item was selected before the user clicked on the control (this determines where the new 'window' pops up) * screen resolution and position of control relative to the top / bottom of the screen - this also determines where the 'window' pops up. Maybe I could do it using relative move movements...