From Friday, April 19th (11:00 PM CDT) through Saturday, April 20th (2:00 PM CDT), 2024, ni.com will undergo system upgrades that may result in temporary service interruption.

We appreciate your patience as we improve our online experience.

G#

cancel
Showing results for 
Search instead for 
Did you mean: 

G# Generic Create hangs with Error 400050

Hej Matthias

I've come across a problem with generic create.

I try to instantiate  classes that are all children of a common ancestor from their path that I locate at runtime.

This worked fine so far  for the first examples (more to come) using the generic_create.vi.

In the same VI (reentrant) that uses that starter I use the ordinary Create - Destroy of one of the modules.

After that (there is no longer a instance in the debugger visible) I try to run the Generic create for the same class.

An Error 400050  occurs but a while-loop is not terminated even though an error happened.   

First:      this is certainly not meant that way.

Second: Is there a problem to use Generic and ordinary creates ? Or how else do I create an instance from a path?

          The examples were not very clear to me.

I'd really appreciate your help

Gabi

7.1 -- 2013
CLA
Download All
0 Kudos
Message 1 of 3
(8,218 Views)

Hi Gaby,

Yes, it appear that you have found a bug in G#Object_GenericCreate.vi the while loop is never ending, which clearly is a bug. Attach you find an update on the G#Object.lvclass with this fixed (LV2010). There are a few other fixes included as well, soon to be released.

The main problem is that your constructor is not idle, but running for some reason. This is what is causing the bug, when G# can't run the constructor, due to it is not idle. Exactly why this isn't idle, I don't know from just watching screendumps. I can't seem to repeat it.

However, I would strongly advise you not to use G#Object_GenericCreate.vi at all. The problem with this VI is that it runs the constructor with VI server and requires that it is in "idle" state as well. When executing, the constructor will for a short moment run as "Run top level" and when finished be "idle" again, causing LabVIEWs own garbage collector to clean up what ever resource you create in your constructor like queues etc. (just as you press the run button on the constructor VI directly).

In order to get around the "Run top level" problem, there is another method called G#Object_GenericDefaultConstructor.vi, this VI will call the G#Object_Create.vi method in your class with a dynamic dispatch call instead and that will cause your constructor to be set as "running" instead of "run top level", like any sub-VI, which is the execution state we prefer, since the constructor would run as any sub-VI, preventing LabVIEWs garbage collector to kick in. There is just one additional thing you need to do when using the generic default constructor compare to the generic create, and that is to implement the "G#Object_Create.vi" in your sub class that you would like to create by pointing out the path (with is what I call dependency injection). This G#Object_Create is just a wrapper of your ordinary constructor in order to get the same connector pane for all sub classes that you want to inject and to get the dynamic dispatch to work. Please have a look at the G#DependencyInjectionUsingDefaultConstructor.vi example. Pay attension "MyG#SubClass.lvclass" and the implementation of the wrapper constructor in "G#Object_Create.vi". I see no problem that you couldn't use this instead.

I must admit that I never use the GenericCreate, I always use the GenericDefaultConstructor instead.

Best regards,

Mattias

Message 2 of 3
(5,633 Views)

Thank you Mattias for your quick response.

What I did not understand with the GenericDefaultConstructor is how the parameters were forwarded. But now also this is working.

I am always amazed how G# is providing all that I need. I get more experienced by time and want more and more. But up to now everything worked out in the end.

Thank you again for that wonderful tool.

Gabi

7.1 -- 2013
CLA
Message 3 of 3
(5,633 Views)