Jump to content

Use "UpdateTerms"-reply from "GenerateCode" ability


SDietrich

Recommended Posts

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.

post-27809-0-32757700-1388090234.png

  • Like 1
Link to comment

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

Link to comment
  • 8 months later...

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. :nono:

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

Link to comment

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

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.

Link to comment

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. 

Link to comment

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Unfortunately, your content contains terms that we do not allow. Please edit your content to remove the highlighted words below.
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

By using this site, you agree to our Terms of Use.