Wolfram

What I mean is the difference in behaviour between LabVIEW 2010 and 2011. In 2011, the VI hangs. But there is also another solution: If you replace the tunnel with a shift register, you can execute the Unregister For Events. BugRegShiftReg.vi

In LabVIEW 2010 SP1 is ok. In LabVIEW 2011f2 NOT ok. Open and run the attached VI first in LV2010SP1, then try in LV 2011f2. Greetings Wolfram BugReg.vi

It's no longer annoying in LV2010. Same behaviour in BD like in FP. Wolfram

Thanks for your hint. I agree with " Ideally, the primitive should have broken the wire...".

Hi all, here is another issue I faced caused by "Not A Number/Path/Refnum" Function in LabVIEW 2010. But I'm not sure, if this is a bug. Wolfram LV10BugRendezvous.vi

Hi folks, attached I have a VI that produces a memory leak. It works ("misworks") in LabVIEW 8.6 and 8.5/8.5.1 but not in LabVIEW 8.2. The attached VI is saved in LabVIEW 8.5. Wolfram

I prefer not to process any callback in the callback VI itself. What I do is to fire events of any callback into a single queue, by which queue element is a cluster of an enum [state or callback name] and a variant [hold the data]. An existing centralized queue state machine will than process all events of all callbacks. Make the enum "state" as type def for easy and fast adding of new states. Wolfram

I've encountered the following bug: See attachment It is one of the bad and strange ones. Wolfram Edit: I've replaced the attachment. There was a race condition in the previous demonstration VIs. Wolfram

Take this control. The trick is to put the text over the icon. Wolfram

ZITAT(tcplomp @ Jul 4 2007, 08:13 AM) See here: forums.lavag.org/index.php?showtopic=8523&pid=32105&st=0& This might help. Wolfram

There is a "BringToFront" method that might be helpful. The "BringToFront" method can be found in the application class. Otherwise you have to use some Windows API functions. Wolfram

ZITAT(BrokenArrow @ Jun 19 2007, 03:03 PM) You can do this when you open the file in loop 2 only as "read only". Then it should work. Wolfram

ZITAT(engineer123 @ Jun 20 2007, 08:43 AM) The calculated time difference seem to be correct. So I don't know where the problem is. Wolfram

Look at this registry key (just read it out): HKEY_LOCAL_MACHINE\SYSTEM\ControlSet001\Control\ComputerName\ComputerName

There is a command called "getmac" to get the MAC address. See in help of Windows XP.