LabVIEW

cancel
Showing results for 
Search instead for 
Did you mean: 

Runtime startup error

I have a standalone executable that I call as an activex control from Excel. The application is built in two parts: 1) a background process that once launched continues running 2) an interface stub that is the VI that Excel actually calls. I split it up like this so that most of the code loading tasks only have to happen once.
 
The problem is that the very first time I run it I see the interface stub window open, followed immediately by a Visual Basic error box that says:
 
         Run-time error '6500'
         LabVIEW:LabVIEW: The VI is not in a state compatable with this operation.
 
I traced the execution of the macro calling the activex control and the error pops up at the line where I am actially calling the VI:
 
         Call vi.Call(paramNames, paramVals)
 
However, once I am past this initial error, I can run the macro over and over again with no problems. However, if I stop the background portion of the code the error will reoccur the next time I try to access the macro again.
 
Any ideas?
 
Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 1 of 9
(3,529 Views)
Hi Mike,

This type of error can be caused if your executable has the Run When Opened property set to True.  What happens in this case is the Call command first loads the VI (or exe) into memory.  Since it is set to run automatically, it begins running immediately.  The Call command next attempts to run the VI, but it throws this error because the VI is already in a run state.  The solution is to make sure that the Run When Opened option on the application is set to False.  We have a KnowledgeBase article on the subject that you may find helpful as well.  Let me know if this works for you, Mike!
Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 2 of 9
(3,507 Views)

Thanks a bunch. This fixed the problem. One thing I noticed about the reference you sent me is that the associated knowledgebase article somehow got filed under:

LabWindows/CVI Development Systems>>Full Development System

In any case, thanks again;

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 3 of 9
(3,503 Views)

Oh yes, one more thing... Now I am getting two windows opened, only one of which shows as running. As soon as I create the object for my application

        Set lvapp = CreateObject("BLOBServer.Application")

a window opens that is not running. When the macro logic gets to where the vi is actually being run

       Call vi.Call(paramNames, paramVals)

a second window opens (over lapping the first one) that is running. When it finishes, both windows close.

This at least doesn't generate an error but it is still not the kind of interface that I would want a user to see.

Mike...


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 4 of 9
(3,495 Views)
This sounds like what would happen if we had reentrant execution enabled on the application.  Have you given this a look?
Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 5 of 9
(3,490 Views)

No, that would have been too easy...  Smiley Very Happy

The issue is that creating the object opens a window that is not running because it was built not to be running. Next when I get to the call statement the VI starts running which causes it to (among other things) auto-center. The problem is that for some reason the screen doesn't fully update - hence you see two images of what is probibly the same window.

My solution is to create a third VI that looks like a typical small  "Please standby I'm doing something" dialog, and does nothing but wait 500 msec and then stops and closes its window. In the builder, I set this new VI as the top level VI and make the one that was the top level VI a dynamic VI - and I make sure that the "Run on Open" strap is set for the new top-level VI.

At run time what happens now is that the object creation statement opens this new VI, which immediately begins running. A few msec later the VI that really does all my application's heavy lifting launches and pops-up over the top of the new VI's window. Then 500 msec after it was launched, the new VI stops running and quietly goes away. All is well with the world...

Mike...

Message Edited by mikeporter on 03-29-2007 04:21 PM


Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 6 of 9
(3,487 Views)
Slick, and a decent workaround.  If you run into any more let me know - I'm curious to know what other curveballs ActiveX is throwing at us.
Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 7 of 9
(3,481 Views)
Will do, BTW is there anyplace where the ActiveX interface to LV is systematically documented? I have some poking around on the web site but haven't come up with anything comprehensive.

Mike...

Certified Professional Instructor
Certified LabVIEW Architect
LabVIEW Champion

"... after all, He's not a tame lion..."

For help with grief and grieving.
0 Kudos
Message 8 of 9
(3,470 Views)
A handy place to look is the Class Browser window (View»Class Browser), this will show all of the properties and methods available for each class of LabVIEW object. 
We expose the properties and methods under the Application and VirtualInstrument classes.  Descriptions of individual properties and methods can be found in the LabVIEW Help, though unfortunately we don't publish a comprehensive document on how to use them via ActiveX. 

Message Edited by MattP on 04-02-2007 10:45 AM

Cheers,

Matt Pollock
National Instruments
0 Kudos
Message 9 of 9
(3,451 Views)