Error 1 Generate user event

[cordm · Accepted solution]

Updating the user interface with user events if totally fine.

The user event is created in New Test.vi, which creates a Test Base instance which is then launched as root actor, correct?

You should only do that if the hierarchy of the launching VI keeps running. This approach is useful when interacting with non-actor code.

If you don't actually send data out of the Test Base actor, it should manage the user event refnum itself. I.e. create it in Pre Launch Init and destroy it in Stop Core (or Uninit in newer versions).

The constructor is a good pattern in general, just keep the reference out of fit. If you don't intend to create child classes you can turn the input class into a constant (or "recommended" input)

Keeping the actor in the shift register in a helper loop is a suspicious pattern. The helper loop and message handling instances will have different internal state, except when using reference semantics internally. If all you need is the self-enqueuer, just read it before the loop.

[dkfire · Accepted solution]

---

@pabolleta wrote:

The user event is created in the "New Test" method. I'm using it as a constructor method, so it's the way I create a new instance of the class.
I know that a constructor method is not strictly necessary in LabVIEW, but it's a good way to keep the code clean.

---

And who calls this method ? 

I would place the creation of the user event in the Pre Launch Init overwrite method. 

That will make sure that the User Event is created correctly in the scope and same level as your actor. 

[pabolleta]

---

@cordm  ha escrito:

Updating the user interface with user events if totally fine.

The user event is created in New Test.vi, which creates a Test Base instance which is then launched as root actor, correct?

---

 That's correct. I call New Test method for creating a new Test instance

---

The constructor is a good pattern in general, just keep the reference out of fit. If you don't intend to create child classes you can turn the input class into a constant (or "recommended" input)

 I see... Thanks for the advice

Keeping the actor in the shift register in a helper loop is a suspicious pattern. The helper loop and message handling instances will have different internal state, except when using reference semantics internally. If all you need is the self-enqueuer, just read it before the loop.

---

 I only place the actor in the shift register in order to get self-enqueuer reference, so I'm not trying to handle instance's internal state.

I'll try to create UE reference overriding PreLunch Init method

[pabolleta]

I've been trying to create a UE by overriding the PreLaunch Init method, and it seems to work.
Thanks to everyone who's been helping!😁

I'm just curious: what could be the reason for the program to fail the first time it runs, but not on subsequent runs? After debugging, there don't seem to be any race conditions. How can the constructor method appear outside the class scope if it's supposed to be a method of the class itself?

[dkfire]

It's not the scope of the class, but more when and in what level the UE was created. 

If LabVIEW thinks that the UE is not in use anymore or the level in where is was created has enden, then it CAN decide to close ( clean up  ) the UE. 

If you look at the Actor Framework, and how an Actor is started, then you will see that it is the Actor that create its queues, and send the reference back to the caller. It is not the Caller that creates the queues. 

This is the same reason as for your UE.