Labview ActiveX Server PATH if in development environment

[ArchivedPointOnePa]

I'm using Labview 2010 to build an ActiveX server.  I can access the executable as an activeX sever from both C and LabVIEW clients.  No problems there.  But now I want to do some debugging in the development environment while accessing the program via an ActiveX client.  In such a situation, how do I change how I access the VI's in the project?  I tried using the lvproj in place of the EXE, but this was insufficient.  Seems a little convoluted with the changes required to do this debugging.

[Peter_W]

To enable debugging in your executable, right click on your application under Build Specifcations and go to Properties. Then you want to go to the Advanced tab on the left and turn on "Enable debugging" and "Wait for debugger on launch" as shown below.

Peter W.

[ArchivedPointOnePa]

Thanks. 

I've not  used this capability before, but now I understand how I can do this.....I learned something new today.

Here's an associated link with more details, just use "localhost" to debug locally.

Remotely Debugging Executables in LabVIEW

http://digital.ni.com/public.nsf/allkb/8DA679805915DE40862572D5007B2F70

I was using the following as an example case:

LabVIEW Executable Used as ActiveX Server in LabVIEW

https://decibel.ni.com/content/docs/DOC-9647

I also learned that while I can change the value of a control, using the ActiveX VirtualInstrument.SetControlValue,  that this will not generate an event that a Labview Event Structure can detect, and if it is a boolean control, it doesn't matter what the Mechanical Properties are; an event will still not be generated.   I'm still trying to figure out how to do this.

Thanks for the info.

[Peter_W]

Hi PointOnePa,

I think I understand what you mean, are you using the Value Change event for the ActiveX control and it's not realising the event is happening when you change the value with the VirtualInstrument.SetControlValue? If so, can you change the value of the control in another way that does cause the event to trigger?

Peter W.

[ArchivedPointOnePa]

>can you change the value of the control in another way that does cause the event to trigger?

That's the questions that I'm asking.

[Peter_W]

Hi PointOnePa,

Are you able to find the event case but it isn't triggering or is the control not showing up in the edit events screen? If you can't find the event case then it is most likely because the control itself you are changing the value of is not in the LabVIEW program so the event structure doesn't see the control that has it's value changing. If you do have the event case set up correctly then could you attach your code to your next reply because I tried to edit the example to referenced and I got hung up trying to add the event case since the control itself is not present.

Peter W.

[ArchivedPointOnePa]

I think that I already have my answer in that I can not generate a LV event through an ActiveX interface regardless of the type of control, but if you want to play with it, here is a Demo which I derived from the previous link given above.  Within the attached ZIP file, read the "Readme.txt" file for instructions.  Specifically the program assumes that is located in C:\tmp, since LabVIEW doesn't like relative pathes in both the build and reference node paths, (so they are coded with absolute pathes).  If you use C:\tmp, the instruction in Readme.txt should work.

What happens is that you click on the button in the ActiveX Client running in the LV development space.

You can see the control value change shade/color in the ActiveX Server EXE application,

but because no event is generated, the Event Handler does nothing.

I know that I can poll the value of the control and then use the Value (Sgnl) property control to generate an event, but this isn't a very clean solution.

All code in the ZIP file is LabVIEW 2010 release1

[ArchivedPointOnePa]

I decided I didn't like the "Reset" pushbutton in the previous demo becuase the value was getting over-written in the server EXE every 250ms, so I added an LED to this version to make it more apparent that the event wasn't being fired when the control was toggled through the ActiveX interface.  So here's version 2.

[Peter_W]

Hi PointOnePa,

I think you're right that the best way to trigger the event is through polling the value even though that isn't the cleanest solution to the problem.

Peter W.