crelf

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.

LV 6.0.2 was a very good version BTW.

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

typedef void *Wind;

Wind h = (Wind)GetWindowLong(hwnd, 0);

should work in all Windows versions I have seen, but of course this is highly under the hood, undocumented and suspect to changes at any new LabVIEW version.

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

In my experience, when you call programmatically a VI you shouldn't have it as a subVI, even if that subVI is never called or is disabled.

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

I'm more concerned that with the number of significant fixes, and a publish date of late February on the download page, I wasn't notified of this patch by NI.

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

It choked on:

LabVIEW 8.0\resource\FrameWork\Providers\lvfp.llb\prefPage_FPEthernetBankConfiguration.vi and

LabVIEW 8.0\resource\FrameWork\Providers\lvfp.llb\prefPage_FieldPointEthernet.vi

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.

Now, get back to work

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!

I hope that you find this useful and it saves you some time so that you can get back to doing the things that you love.

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!

Take the day off and go have some fun. :thumbup:

Did that yesterday - went skiing

...I suppose I could go surfing if I, say, lived right on the beach...

I thought that Windows XP has got multitasking

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?

Maybe not the cleanest solution, but it works.

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?

Hey, I like the flying eagle on the side. Similer to the NI logo I guess.

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

You don't just don't need it, you can't wire it to use the Run method. Wiring the type specifier reserves the VI for Call...

Ahhhhh - of course it does! Thanks for your help!

...why are you not using the CBRN to invoke the plugins? If you are enforcing a strict con-pane adherance of plug-ins, then this might be the best approach.

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"

But when "A" (running as a standalone application) tries to start "B" (also running as a standalone application) then "B" will open up broken.

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

To use the Run method, don't input a type specifier when you open the reference. You need a type specifier only for calling the VI with the invoke node.

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.

...you can still monitor the mouse movements using the Mouse Device VIs and figure which item is highlighted.

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

Hey all,

I'm using VI server to load and run a VI dynamically, but I'm getting:

Error 1000 occurred at Invoke Node in Start Threads.vi

The VI is not in a state compatible with this operation

I know the VI is fine (it's not reserved for executiong, I can run it manually, and it's idle when I try to call it).

Note the image over the title of the type specifier - I wonder if this is trying to tell me something?

Anyway - see the attached files: unzip the zip file to a new folder and point the path control of LittleBugger.vi to that new folder - I can't understand why the Motion (Linear) Thread.vi won't run...

Download File:post-181-1141424835.vi

Download File:post-181-1141424750.zip

This one's got me completely stumped: I'd like to fire an event (or the like) when you move between different options in a combo box.

That is, you click on the box to get your drop down options, and as you move the mouse over the items in the list, I'd like to programmatically change the description of the combo box:

Any ideas? It's driving me nuts!

Download File:post-181-1141401289.vi