crelf

Everything that Jim and Mike said - it's like Info-LabVIEW in a rich environment. Just curious: why do you ask? Is it because you're aiming to make the NI discussion forums more like LAVA?

Crikey! You must have a lot of global accesses in there - looks like most of your CPU was being taken up by obtaining mutexes and thread swapping A great demonstration of another reason why globals are evil!

It's easier in terms of time and work to implement, but XControls abstract the data handling you use just to display it, so your code is more readable (eg: you're not cluttering up your main BD with code that just rotates an array and picks off a few values to get them onto a graph) and generally easier to debug. Sure, you could just have all the code on the BD or put it into a subVI and then into your FP node, but XControls really clean all of that up. I also agree that using them in different places and across different projects is certainly useful too...

Changing the world, one VI at a time. That's just *sniff* beautiful!

Ahh - gotcha. Staying tuned with great interest...

I've had the same problem with VIs called from TestStand - anyone from NI care to comment? Perhaps provide a CAR?

I don't really think their use is really valuable for multiple instances (you can save any normal cutomized control for that), but for when you want to build functionality into a control - sort of like the difference between a standard VI Global (just holds data) and a Functional VI Global (holds data and performs some work on them).

Sure - there's nothing new in dqGOOP, but it's a particularly eloquent implementation of it - and also a IMHO great place for those unfamiliar with OO to start understanding the concept.

C'mon Pete - I know that you've got a plethora of more keyboard shortcuts Have you ever thought of putting them all into a new thread?

Now if only the LabVIEW Runtime Engine was small... :laugh:

Come to think of it - that means that you could write to a global and then read from it again before it's updated. I know that globals inherently lead to race conditions, but the statement above means that even if you force dataflow so a global is written on your BD and then later read, there is no gaurantee that the write happened before the read...

That's right - locking a VI in Run Mode stops the user from selecting anything on the diagram, so they wouldn't be able to copy anything out of it.

Yes they do (from "VI Execution Speed" on NI's website): How Multithreading Affects User Interface Actions When you write to a local or global variable, LabVIEW does not switch to the user interface thread immediately. LabVIEW instead writes the value to the transfer buffer. The user interface updates at the next scheduled update time. It is possible to update a variable multiple times before a single thread switch or user interface update occurs. This is possible because variables operate solely in the execution thread. Functional global variables can be more efficient than ordinary global variables because they do not use transfer buffers. Functional global variables exist only within the execution thread and do not use transfer buffers, unless you display their values on an open front panel.

:2cents: Now that's a good idea - and you're right, it shouldn't be too difficult to implement, as all you're really talking about is making the "Change to Edit Mode" functionality password protected at the VI level - the users could still open the VI, run it, see the BD, even open subVIs, but they wouldn't be able to edit the diagram...

Sweet! Now everyone's going to be watching your slogan Jim - choose carefully...

Very very interesting - thanks for doing the research!

Personally, I'm a big fan of GOOP using queues (I'd implemented my own version prior to the dqGOOP release, but the dq version is a lot cleaned than mine) - it's easy, fast and covers a lot of what I need to do (I'm certainly not a GOOP 'power' user). I'd sure welcome an openG version (is there any legal issues here? Can OpenG release an open under LGPL that's very similar to the dq version?) Does anyone have any ideas of what's under the LabVIEW OO engine (soon to be realeased)? Is it going to be queue based, or something else entirely?

Also, changing anything on the BD between subsequent runs causes the VI to recompile, meaning that the memory space is reallocated. These two methods sort-of demonstrate the different behaviour between runs, but they unfortunately don't fix the bug - that's NI's job :laugh:

LabVIEW does indeed have issue with opening large files - what you need it the "Large File" package from OpenG - download and install the Commander and you'll be able to get access to all of the packages...

Probably: head over to the Beta Program Website and register - then they'll contact you if you've been selected...

.NET and ActiveX are far more than just controls - my question is: if we can do Win32 DLL calls, can we do cusom ActiveX DLL calls under RT? I'm thinking that the answer is most probably going to be "no"...

Can you post a range of example images alng with a description of the region you're interested in?

I don't know - it's just a DLL...

I've had great sucess with Port Controller in the past, but never tried it on an RT system...

Just imagine it - a LAVA user group meeting, with everyone in thongs... . . ...then again, you probably shouldn't