How can I get notification that a callback vi has closed

[SteveMoores]

I have registered an event and have a callback vi which runs on an ocurrence of the event. My original vi requires notification that the callback vi has closed or completed. Does anybody have any sugestions ?

[PNHorn]

Hi Steve,

It's Pete from NIUK Tech. Support here. I've been having a look into your problem. I have a few questions for you together with some possible solutions.

How is you callback vi called in your main vi. Is it just called as a subvi or as a totally separate vi. If it is a subvi you could just pass out a variable on completion of the task. If it is a separate vi then the best option would be to write a variable to a global variable and then have the main vi polling that global variable to see when the value changes.

This could impact the efficiency of your vi and therefore if this is important, get back to me and I can have a look into some other possibilities for you.

Best regards,

Peter H.
Applications Engineer.
National Instruments.

[SteveMoores]

Hi Pete

thanks for taking the time to look at this, I am using a callback vi in exactly the same manner that it ised in the ActiveX Event Callback for Excel.vi example in the help system.

right clicking on the vi ref node of the Reg event Callback component allows me to select create callback vi. However, I have created a vi with a connector to this node so that I can re-use my vi in the future by simply adding a vi ref to the node.

Is the callback vi when created in the above manner and as shown in the excel example treated like a sub vi ?

It may help if I explain what I am attempting to do here in more detail ???

I have several automation interfaces in some code writen in C++, I have written these interfaces to allow custom control of t
he main software suite through LabView or any other COM enabled langauge, c++, VB, VBScript etc etc.

The interaction requires the following steps,
1) Set a flag through the interface to request notification of an event i.e anble event firing
2) On receiving an event handle it through a vi
3) On completion of the event handler vi acknowledge that the event has been handled by clearing the flag through the interface.

I would like to provide a vi which wrapped all this functionality, to make the vi re-useable I would need to be able to bring th vi ref ( the event handler vi ) to a node as an input on the collector pane. This would enable me to handle different events in differing ways by simply using this node.

I hope this is clear, any advice as to which would be the best approach would be appreciated. The global variable method may be the only way if I want to wrap all the functionality as passing a variable out of one vi on completion and then feeding that output back into
the main vi as input does not hide the implementation details from anyone else who may wish to use my vi...

Cheers

Steve

[Greg_McKaskle2]

> Is the callback vi when created in the above manner and as shown in
> the excel example treated like a sub vi ?

The callback is a VI that is called when the user fires the event and
returns to the event firing. I don't really think you need notification
the event has been handled since ActiveX doesn't really post events, but
instead they are just function calls through and event wrapper.

> I would like to provide a vi which wrapped all this functionality, to
> make the vi re-useable I would need to be able to bring th vi ref (
> the event handler vi ) to a node as an input on the collector pane.
> This would enable me to handle different events in differing ways by
> simply using this node.
>

I'm still not certain I understand wha
t you are intending to do, but I
think you have plenty of flexibility, just don't make it more
complicated than you need. Afterall, you can also build the VIs into a
DLL can use that from your ActiveX component. If the invokations make
sense to invoke through events, then the callback VIs make sense, but it
really depends on whether this will make sense to the user of what you
are building.

Greg McKaskle

[PNHorn]

Steve,

I've read through what Greg has written (thank you for your input by the way Greg) and was just wondering you feel you can get to a solution from here or if you have any further questions. Please get back to me if you do have any further questions.

Best regards,

Peter H.
Applications Engineer.
National Instruments.

[SteveMoores]

All responses have helped to some degree, Greg suggested that I did not need to acknowledge that the event had been handled, this would be true under normal circumstances. But, events are being triggered fom a state machine in my main C++ app, these events would normally be handled by another app in c++. However I am developing a system which will allow LabView developers to hook into our app with their own custom code and as such acknowledgement is essential to ensure that the state machine is made aware of the current status of the user code. I could use a sub vi as you suggested which would remove my problems - but I was looking at creating a generic vi which developers could use - clearly a sub vi could only contain 'generi
c code' and not code specific to user requirements. As a first example I could provide users with a sub vi approach - but only as an example as how they could develop their own system. I am currently looking into geeting the callback vi to generate a user event to signify that the event had been handled which could be picked up by the main vi ...

I hope this make sense to you ?

regards

Stephen

[Greg_McKaskle2]

> code. I could use a sub vi as you suggested which would remove my
> problems - but I was looking at creating a generic vi which developers
> could use - clearly a sub vi could only contain 'generic code' and not
> code specific to user requirements. As a first example I could provide
> users with a sub vi approach - but only as an example as how they
> could develop their own system. I am currently looking into geeting
> the callback vi to generate a user event to signify that the event had
> been handled which could be picked up by the main vi ...
>

Sorry if my initial feedback was too abrupt. This additional info helps
a bit with understanding what you are needing to do.

You mention that a subVI could onl
y contain generic code and not code
specific to user requirements. I'm not sure I follow. Using the VI
Server, you can load and execute dynamically loaded VIs from either LV
or through ActiveX. This can allow for synchronous code that the user
drops off by placing into a directory or registering through some other
manner. Of course you can also use this as a way to synchronize with VI
wrapped synchronization objects built into LV, or you can call system or
third party synchronization from both LV using the DLL node and from
your C++ code.

Personally I'd go for the call unless you need notification during their
execution and not simply at the end of the VI.

Greg McKaskle

[SteveMoores]

Greg

Thanks for the response, as I am extremely new to LV I am not aware of many of the options available to me.

I shall look into some of the areas you have suggested above.

To add to the problem it may be required that the 'event handler' acknowledges the calling function either after completion of the handling code or before execution of the main handling code. This will be dependant upon what the user is attempting to do.

the user may wish for the main C++ app to continue execution and continue following is state machine, this would be achiebed by the 'event handler' acknowledging before executing any user LV code.

Alternatively the user may wish that the main c++ app holds off while the use
r LV code performs some action, on completion of the 'action' the acknowledge flag could be set which is picked up by the state macine and the main c++ app then continues on its merry way.

Apologies for adding this extra bit in but exact requirements have been a bit fluid !

Would I be best to simply use a global variable ? Not nice I know !

It would appear from my 'learnings' over the past few days that I cannot simply use a sub vi for two reasons:

1) The event data of the call back vi must match the event data , this would mean that all my events would require a 'return' or 'event data out' value - clearly 'events' where not designed with this in mind as they are not synchronous.

2) the ack may be required at ANY stage within the 'event handler' code - the sub vi would only pass data out at the end of the user code !

Without looking into the use of synchronisation objects it may be that I need to use global variables

OR

I change my com interface to allow for po
lling rather than being event driven...

Thanks for the comments and discussion , I am finding that by simply discussing thhe issues I am gaining a much better understanding.

best regards

stephen

[Greg_McKaskle2]

> Thanks for the comments and discussion , I am finding that by simply
> discussing thhe issues I am gaining a much better understanding.
>

Unfortunately, I still have very little information about what you are
trying to do so my comments have to be heavily guess based. Let me
describe a little bit about how LV and TestStand plug together and that
is one possible way to mke things work for you.

TestStand can operate in a standalone mode or pulled into a user
program, anyway, it allows for calling to a VI to carry out a test.
TestStand passes values into the subVI and initiates the call. One of
the parameters is an interface for communications back to TestStand.
This is used to gather
additional parameters that aren't directly
provided, or to update other values stored in TestStand, or to notify
TestStand of progress. Sometimes the subVI doesn't use these mechanisms
and it is a simple subVI call, but the capability is there and it is
pretty simple for the subVI writer to take advantage of them when they
are needed.

If you have a very clear description of what you are looking for in
terms of data in, data out, intermediate notifications, and synchronous
versus asynchronous execution, you should try to state those clearly,
even if just for yourself. This model will be the fundamental thing to
define the interaction between your app and LV, and if it changes often,
you will end up with lots of rework and most likely not very nice code.

Another option you might want to consider. LV makes it very easy to do
asynchronous tasks and to synchronize things later. If it allows you to
simplify things, you might consider making a LV engine that deals with
thes
e things and you always call that from your C code, either
synchronously or asynchronously. This hopefully means this interface
doesn't change as much, but the LV to LV interface can offer more
options and change more often without disturbing the rest of the app.

Greg McKaskle