Error 1 Generate user event

[cordm]

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]

---

@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