accessing imaq objects using pointers

[mps]

okay, it's up there and it's called scaledown.zip

I'm interested to find out if you think it will work.

[drohacek]

I haven't reproduced the error that you are seeing - I need to get hardware. Looking at your program, I see that you are calling CoInitializeEx in the main thread. I think you intended to call it in your worker thread because that is the thread that calls into the control to check for the trigger.

However, I don't think this is going to solve the core problem. You are accessing the control from two different threads, which is not allowed without marshaling the interface pointer between the threads.

I'll get the hardware and give it a look. Have you tried using a Windows message to cause the trigger query to occur in the main thread?

[mps]

The part that really confuses me is that if I put the m_cImaq.AcquireImage() call inside the View class it doesn't produce an error at all. This is strange because the application is still multi-threaded. The only thing that I can think of is maybe MFC has some internal marshaling built in, so when I put the call inside the view (an MFC class) it handles that automatically. But I'm just grasping at straws.

I guess there is an easy hack. I could just put the AcquireImage call and GetImages call inside the view.
I don't like this idea though.

[drohacek]

I'm certain that MFC does not marshal COM interfaces for you automatically. The Measurement Studio C++ classes for the user interface controls (e.g. CNiGraph) add this functionality explicitly. Unfortunately, there are no such C++ classes for the IMAQ controls.

I was not able to reproduce the exception you get. I tried a couple of different things, including causing the the acquisition to happen at different times.

After thinking about the problem some more, I realized that you would not necessarily get an error by calling into the interface from the wrong thread. The COM server is just a DLL loaded in the process, so there is nothing p
reventing the call from happening. However, the control implementation is not thread safe. Being an apartment threaded COM server, it expects to always be called on the same thread. As you probably know, calling code that is not thread safe from multiple threads can result in errors in some cases and not in others, depending on the timing of the thread accesses and what shared data is being accessed. If this is what is going on, it could explain why moving code around changes whether the error occurs and why you see the exception but I don't.

I am attaching updated versions of your trigger and view classes. These updated versions use CoMarshalInterThreadInterfaceInStream to properly marshal the COM interface for the signals to your worker thread. I included some comments, marked by drohacek, around the code that I modified. Could you plug this in and see if you still see the problem on your machine?

[mps]

I tried the marshaling but it really bogs down the application. Once I start the thread the application UI starts running really slowly. Is this common when using the marshaling technique?

[mps]

I'm sorry, but I was mistaken in my last post. My application wasn't responding correctly because the Duncan Tech software was running too.

I still get the same error though when trying to acquire.

[drohacek]

Well, that isn't very encouraging. I'm a little stuck for ideas without being able to see the problem on my machine. Can you give me any ideas on what I might try to get the problem to reproduce on my machine with the test project you sent? Does this happen with the debug version as well as the release version? If it does happen with the debug version, can you enable Just-In-Time debugging so that you can see where the breakpoint is that is causing the exception?

If this doesn't lead us anywhere, you're probably going to need to contact NI support (ni.com/support) to get more direct support on this issue.