02-04-2009 09:50 AM
SetupViewerForRotatedRectSelection task: (axCWMachineVision1.SetupViewerForRotatedRectSelection(axCWIMAQViewer2);
I an error indicating invalid arguments: Error 2 Argument '1': cannot convert from 'AxNationalInstruments.CWIMAQControls.AxCWIMAQViewer' to 'NationalInstruments.CWIMAQControls.CWIMAQViewer' E:\MPM Upgrade\MPM\Main.cs 2246 67 MPM Screener
Solved! Go to Solution.
02-05-2009 02:22 PM
Hey bob,
I guess I have one main question for you:
Why are you using the ActiveX controls instead of just referencing the CWIMAQ class? Basically your program is not working with your AX functions because it is expecting the non-Ax functions. So, why not just use the National Instruments Vision library instead?
02-05-2009 03:04 PM
You are probably right in that this will come down to something I just don't know how to do. These are the two things that I can do as I understand them:
1. Add the controls to the toolbox, drag and drop them onto the form and go from there. As I drop them, VS2008 creates a form object giving it the AX prefix. This is an object that your dll cannot accept.
2. Create an instance of a viewer by referencing the class. This creates a viewer which your dll can accept but I do not know how to show it and interact with it like a form object at runtime.
There seems to be a catch 22 here
02-05-2009 03:18 PM
Hey bob,
You'll have to bear with me a little bit, as I will admit that I'm not a huge text-based guru, but from everythign I've dealt with in Vision and VS, the functions have not had the Ax prefix. You might want to look for the normal (COM library I believe) for Vision, which should no longer have the Ax prefix.
I am looking into this further though, to try to get you a solution.
02-09-2009 02:13 PM - edited 02-09-2009 02:14 PM
You had a good point Chris, however, it was admitted from Vision Team that IMAQ for Visual Studio was not a "Native .NET". They utilized a wrppaer classes that in some situations made many of us unhappy. you may observed "AX" prefix in "AxCWIMAQ" and other components that you can infer that from.
The good news were carried out by the Vision Team Project Manager that the new upcoming version is a "Native .NET" which will make all .NET devs happy as much as their LABVIEW peers (no hard feeling for our LABVIEW mates )
You are correct as all functions don't have that prefix, however, since it is derived somehow from COM, you may expect some issues. Does it sound rational ? I do appreciate your opinion
02-09-2009 03:02 PM
You are correct that Vision is currently not native .NET, but that is being fixed as we speak with the new release.
As far as the CWIMAQ functions causing problems due to being derived from the COM library, I wouldn't really expect any issues. Like I said though, we deal with the CWIMAQ function quite frequently, but never the Ax version of it.
You could also request to beta the new vision development module with native .NET support. Just go toni.com/beta and select the software from the drop-down list.
02-10-2009 08:12 AM
I have gotten the solution to this issue. The following example program will show things better than I can explain them. http://forums.ni.com/ni/board/message?board.id=200&thread.id=14376
I still wish there where more detailed explanations of the methods and argument options for third party programmers as NI generally does for the other products I have used but I am up and running in the right direction now. Thank-you all for the assistance.