mdennie

Can you have the brat VI dynamically register for the value change event on the control, and ignore the change in value that gets observed on the next poll? if you notice a change in value while polling, disable the dynamically registered event (wire in a not-a-ref) before writing to the value(signaling) property, and re-enable it after.

I've got LabVIEW 2012 and I checked the Example Finder under "New Examples for LabVIEW 2012". The only example listed is "TDMS Defragment - Fragment Indicator.vi." Does anyone know where the "promised" example can be found?

Has any found a solution to _predicting_ 'memory is full' errors? I know all about reducing memory usage and dividing up memory blocks, but I'd still like to know how to avoid being unceremoniously dumped from my application when it hits the limit. If I'm about to acquire a large dataset at the user's request and there isn't a large enough memory block available, I'd like to inform the user and recover.

I'm very interested in solutions to the problem of multiple developers working in a single project. I've been trying to figure out how NI envisioned this would work. If LV8 is supposed to provide an environment for large, multi-developer projects, surely someone considered that more than one person would work on a project at one time and that the project would be under source control. I was expecting to see an article from NI somewhere describing a suggested practice, but so far at NITS and in other conversations with NI folks I've gotten nothing but blank stares concerning this issue. How are changes to a LV project managed when multiple developers are working in the project simultaneously? Has anyone encountered this yet? -- Matt

At first glance, building a fairly simple example executable in LV8 results in an EXE of just over 1 MB. Creating an installer results in a folder 'Volume' consuming almost 70 MB. Sheesh! Part of this is the LV Runtime installer (about 20 MB), and part of it is the Math Kernel Library (about 6 MB) I just read about in a related thread. But what is all the other stuff {'MU' (2 MB), 'MDF' (8 MB), 'svcloc' (1.4 MB), 'logos' (13 MB), 'license' (the Engilsh license is 65K but the Korean license is over 1 MB), and 'support files'} and are there ways to reduce it? Any help or suggestions are appreciated, or links to similar topics elsewhere (I haven't found any). Thanks, -- Matt

If history is any guide, there won't be a release of bug fix full installer (even to SSP customers). I voted for one, though.

NI support says it'll be a few weeks before an RTE installer will be available... However, building an app installer from an updated system should install the updated RTE, right? Also, 8.0.1 built apps are supposed to run with the 8.0.0 RTE. No word on what actually changes in the 8.0.1 RTE. -- Matt