@Randy H wrote:
John,
What are you programming DAQmx Base in, LabVIEW or C? What hardware are you using? DAQmx Base is implemented in LabVIEW and this is causing the issue you are seeing. We need a couple of front panels to pass data back and forth. Also, the LabVIEW Run-time Engine also launches some items that could possibly interfere with messages passed among the windows. We have seen this before as double entries in a Cocoa help menu and not being able to double-click on a file in Finder in the application. Unfortunately, this is all a LabVIEW issue that we have reported to the LabVIEW team and they are investigating.
Please let me know how you are interacting with the NI-DAQmx Base driver and I will try and help you the best that I can.
Randy Hoskin
Measurements RLP (NI-DAQmx Base)
National Instruments
Randy- Thanks for the info. My reply was delayed by being on vacation for a week...
So DAQmx Base makes a Labview front panel to run things. I guess that's not entirely unreasonable. It would be nice if it didn't wind up as a window in our process (which puts the window in our window list).
I'm doing this in C++; it's a Carbon/Mach O plug-in for a CFM application. So far I'm testing with a PCI-6014 but the plug-in will ultimately be used with any multifunction DAQ board supported by DAQmx Base on OS X.
The problem is that the parent application walks the window list and assumes that any window (that's not one of the special windows added recently in OS X) is one of ours. De-referencing a pointer to our data structures for a window that doesn't have those data structures simply doesn't work
🙂My task this week is to install a work-around in the parent application that allows us to identify our own windows.
Again, thanks for the info.
John Weeks
WaveMetrics, Inc.
Phone (503) 620-3001
Fax (503) 620-6754
www.wavemetrics.com