Jump to content

Why is it so difficult to do seemingly simple things in ActiveX?


Recommended Posts

OK, I'm having two big problems with ActiveX.

Problem #1 is trying to get Matlab to call a LabVIEW app. Simple enough from the LV end, just turn on the VI server.

Seems simple enough from the Matlab end:

e=actxserver('LabVIEW.Application');

vipath='c:\Documents and Settings\nosflowm\Desktop\testx.vi';

vi=invoke(e,'GetVIReference',vipath);

I can run the VI with:

vi.Run or vi.Call or vi.Call2

The trouble is I have no idea how to pass parameters to the VI and how to read back the output. I've munged together that I can set the input arguments the hard way:

vi.SetControlValue('input variable1',4);

But if I try to use the NI suggested method "Call" or "Call2", Matlab chokes on any input parameter I specify:

object.Call2([paramNames], [paramVals], [openFP], [closeFPAfterCall], [suspendOnCall])turns into:

>> vi.Call2('input variable1',5)

??? Invoke Error, Dispatch Exception: The parameter is incorrect.

Any ideas?

Problem #2 involves interfacing with a VisualBasic program developed by a third-party for a piece of hardware, and he's really reluctant to help debug anything.

I can sort of munge things into working by embedding his OCX into a global variable and have each subVI in my app refer to it. But it just feels wrong, and I have to implement a signaling channel to prevent contention. I should be able to create a reference and pass that between VIs. Only problem is that it fails miserably, giving me Error code -97, and when I probe the line, it has a null reference to the ActiveX interface.

That's the easy part. The hard part is that I want to write clean code. That is, I want to initialize the instrument when I start my top level VI and close it when I'm done. But somewhere things don't close out cleanly. Which means that every time I want to test my code, I need to restart LabVIEW, or the ActiveX server thinks that someone else is controlling the hardware interface (4 serial ports). How can I fully close down the ActiveX object without restarting LabVIEW?

Sorry if my jargon is off, I've never worked with ActiveX, COM, or NET before. Any help would be appreciated.

Thanks,

-- MW

Link to comment
  • 2 weeks later...

QUOTE(nosflowm @ Feb 27 2007, 05:11 PM)

That's the easy part. The hard part is that I want to write clean code. That is, I want to initialize the instrument when I start my top level VI and close it when I'm done. But somewhere things don't close out cleanly. Which means that every time I want to test my code, I need to restart LabVIEW, or the ActiveX server thinks that someone else is controlling the hardware interface (4 serial ports). How can I fully close down the ActiveX object without restarting LabVIEW?

I'd love to know the answer to this last question as well. I've got a front-end application written in LV8.2 that pulls data (picture + various calculated variables) from a Spiricon laser-analysis program which has an ActiveX interface. The ActiveX implementation of the Spiricon code tends to hang and crash the application. If Spiricon crashes, (or much more rarely, LV crashes), it takes the ActiveX interface with it, and the only way to recover is to shut down and restart both the LV and the Spiricon applications. If I could clear the ActiveX object from Labview without having to restart the LV EXE, I could handle the error on the fly, restart the Spiricon application, and open up a new ActiveX link.

Any windows guru's know how to clear an ActiveX link?

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.