registering user events in a loop

[wiebe@CARYA]

---

wiebe@CARYA wrote:

---

@cbutcher wrote:

Well, I don't think you're using Run VI, so there's a chance you can make it work so long as the VI that opens the reference doesn't go out of memory (I think that's what the help is saying).

---

If that is what the help is saying, the help is wrong.

---

BTW this is easy to prove.

Spoiler

 Make a VI A that creates a reference (any reference, a queue, a file, a user event, or an event registration). Put it in an indicator.

Make a VI B that uses the reference from a constant.

Run VI A, and copy it's indicator.

Paste and replace it in VI B.

The reference will have a value, but it won't be valid. VI A is still in memory. If you put a long wait in A, or an event structure that never fires, VI B will work if you can get A's indicator copied.

Spoiler

 Now you put A in a sub VI C, and another instance in D. Pass the reference from A through the connector pane. Make D run forever.

Run D.

Run C, and copy the A's output to B.

B won't be working with C's reference. A is still running though.

If you copy A's result from D and paste it into B, B will work.

[PaulOfElora]

Thanks for your help, guys.  I'll to communicate more clearly what I'm trying to do, with these snippets.  When I wire the "InternalEventRegRef" registration refnum to an event structure *from within the VI where it's created*, it works - I can 'see' the event data.  But when I pass it *out of the creating VI* and try to use it, the event data is 'gone' - I can't actually use it anymore.

The big picture - I'm trying to create a timer that can be copied and used many places in an application.  What I'm looking at now is a sort of 'binary' approach, where, for each timer required, I have 2 coupled VI's - an FGV that creates 2 events (one 'internal' and one 'external'), remembers the time to set and such, and another VI consisting of only a 'naked' event structure.  I've never seen anything like this, probably for very good reasons, but I'm intrigued by the possibility that I could (in my mind at least!) start a timer from 2 different calling processes, so that either starts the timer running, in either order.  When the 2nd process calls it and starts it, I want the timer to *restart* if it's in 'restart mode', and ignore the 2nd if it's in 'lock mode'.

I'm at a point in my LV education where I'm starting to tiptoe towards using classes, and I think that maybe this is a classic case for that.  But I'm not quite there yet.  Thought I'd get this working 1st without classes, then implement it as a class.

[PaulOfElora]

As we hippies used to say "Whoa dude, that's really heavy!" I gotta try this and wrap my mind around it.

[wiebe@CARYA]

It could be as simple as the value of the function enum.

The default value in the case doesn't have to be the default value of the enum. And the default value of the enum might not be used if it's not connected to the CP, or it might not be init.

Put a probe on the registration wire, see if it's a number coming out of the VI.

Can't review it, still in LV2018.

[PaulOfElora]

Sorry about that, here are my 'binary VI's' in 2015.  BTW I had trouble following your instruction to '... VI B will work if you can get A's indicator copied.'  I wasn't able to grab/copy A's indicator *while it was running* - guess that's not you meant

[wiebe@CARYA]

---

@PaulOfElora wrote:

Sorry about that, here are my 'binary VI's' in 2015.  BTW I had trouble following your instruction to '... VI B will work if you can get A's indicator copied.'  I wasn't able to grab/copy A's indicator *while it was running* - guess that's not you meant

---

That was exactly what I meant. It's not trivial.

In stead of copying the indicator, copy the data. Right click the indicator and select "Copy data".

Of course you can do it automatically with VI server 😁.

I didn't expect anyone to actually execute those steps. I hope the steps solid 😊. I'm pretty sure about the principle though.

[wiebe@CARYA]

The event structure in the FGV is preventing the FGV VI from stopping.

Turn on highlight execution to see this. Or open the FGV, and see that it's still active.

You created a deadlock. The FGV waits for an event, the main VI waits for the FGV...

[PaulOfElora]

Holy cow - 'Copy Data'! I never noticed it.  I guess that means 'don't copy the actual object (instance of a class?) - copy just the data it carries (the child's data)'.  Gotta dig down into this.

[PaulOfElora]

h I know - I was just making stay running forever

[PaulOfElora]

I responded to the wrong post - I didn't intend for the event structure in the Timer FGV to actually do anything - I just used it to test whether I could access the Registration Refnum's event data.  So the reference was valid *inside* the vi where it was created, but once it passed out of that vi, it 'became invalid'.