Use "UpdateTerms"-reply from "GenerateCode" ability

[SDietrich]

Hello my fellow XNode scripters,

 

I recently ran into an issue developing my latest XNode. I want to break certain wires connected to my xnode, based on the results of the "GenerateCode" ability. Basicially I generate the code, check certain wires in that code and if they are broken, I want to break the corresponding wires to my XNode.

 

But LabVIEW keeps ignoring my "UpdateTerms"-reply in the GenerateCode ability. Has anyone else had a similar problem and probably solved it?

 

Interesting fact: the reply "UpdateImageAndBounds" is also ignored, whereas the reply "UpdateImage" is processed correctly...

 

Merry X-mas,

 

Sebastian

 

PS: The XNode I am working on is basically a wrapper around the FormatIntoString() node, that accepts (nested) clusters and simply unbundles them (recursively). See attached screenshot. When this and some other minor issues are solved, I will publish the XNode here @LAVA.

[SDietrich]

Hi all,

 

I just wanted to let you know the solution to my problem is no blocker anymore as I found a workaround. I can now simulate the environment for GenerateCode and thus find out which wires need to be broken right in AdaptToInputs. This information is then saved into the State and used in GetTerms4. So there is no need to have GenerateCode reply with "UpdateTerms".

 

The key to this simulation is the (private) method "Create Constant" of the "TopLevelDiagram" class. It is used to create constants of the same datatypes as the wires connected to the XNode.

 

It might still be interesting if there are other limitations as to what ability can answer what reply.

 

Regards,

 

Sebastian

[Sparkette]

Hi all,

 

I just wanted to let you know the solution to my problem is no blocker anymore as I found a workaround. I can now simulate the environment for GenerateCode and thus find out which wires need to be broken right in AdaptToInputs. This information is then saved into the State and used in GetTerms4. So there is no need to have GenerateCode reply with "UpdateTerms".

 

The key to this simulation is the (private) method "Create Constant" of the "TopLevelDiagram" class. It is used to create constants of the same datatypes as the wires connected to the XNode.

 

It might still be interesting if there are other limitations as to what ability can answer what reply.

 

Regards,

 

Sebastian

 

Uh oh, looks like somebody's using a private method in production code.

In all seriousness, that one seems innocent enough, but the truth is you never know; it's probably marked private for a reason.

[hooovahh]

Uh oh, looks like somebody's using a private method in production code.

In all seriousness, that one seems innocent enough, but the truth is you never know; it's probably marked private for a reason.

Not quite.  When the EXE is made there is no XNode, and there is no private method being used.  The private method is only being used during edit time.  If you interact with the XNode described it will call the private method, but once it has ran, that private method won't be found in your source.

 

So it is a grey area for sure.  The production code doesn't contain any private methods, but a tool used to generate a portion of the production code does.

[Sparkette]

Oh in that case I would guess it's okay. I didn't pick up on that part. Though there's still no guarantees. And you wouldn't want to use one like Genericity.

Edited September 2, 2014 by flarn2006

[hooovahh]

Oh in that case I would guess it's okay. I didn't pick up on that part. Though there's still no guarantees. And you wouldn't want to use one like Genericity.

Correct me if I'm wrong but Genericity (is that a word now) makes the VIs on the fly and saves them to temporary file locations on disk.  One for each instance needed to support the VI.  Essentially making a new polymorphic instance every time one is needed.  I have no clue how that would work in a built EXE because scripting isn't in the run-time engine.

 

But now that I think about it when building an EXE it would probably just replace the generic subVI with the instance it created that was being used.  If that is the case then again a built EXE using a VI that uses a Generic terminal, should be identical to a EXE built with just a normal subVI.  But really I have no idea what the compiler would do, which is probably why NI just advises against using them at all.