DWarn from Xnodes

[jdsommer]

This is about a problem that I had with xnodes and its resolution, just any case some other poor sap finds themselves in the same situation. There may be others that have done more research on xnodes that are aware of this, but I didn't come across any info when searching.

 

In a set of xnodes I recently created, I attempted to have ModifyCode called immediately after GenerateCode. The last step of GenerateCode, in my case, was always going to be identical to the complete step for ModifyCode. Since GenerateCode has a Response output, I thought a nice clean way to do this would be have GenerateCode respond with ModifyCode. I was wrong. All this does is

 

a) Not call ModifyCode

 

and

 

b) Cause LabVIEW to throw a DWarn on exit.

 

 

Perhaps some more experienced xnoders have some insight as to why what I tried didn't work. In any case, I resolved it by having GenerateCode directly call ModifyCode rather than just responding.

 

 

[hooovahh]

Very interesting.  So let me see if I get this straight because I've actually never used the ModifyCode Ability.

 

So GenerateCode is for making the code that the XNode executes.  What is common is to call this from something like AdaptToInputs after a new input has been wired.  Often the GenerateCode ability will use a template VI instead of scripting from scratch for simplicity.  So you can plop down a template VI, and wire up the terminals to the wires of the diagram, and this is the VI that is ran when the XNode executes.

 

ModifyCode sounds like it is used to modify the already made VI, created when GenerateCode was called.  For this reason I can see why you would want to try to call it after GenerateCode.

 

In my development I've only ever used GenerateCode and I would remake the VI with scripting each time.  I'm betting that in some cases a ModifyCode could be called to modify the already made VI, making that operation quicker.

 

In some of my VIs I keep track if GenerateCode has ever been completed once and behave slightly differently if it has, so that code doesn't get re-generated all the time when it doesn't need to.  I'm guessing I could do something similar where if code has been generated I could call the ModifyCode instead for faster editing of the VI.

[jdsommer]

Yup, you've got the main idea of ModifyCode, so far as I'm using it anyway. Since I've got xnodes in xnodes in xnodes, completely regenerating the nodes was taking an irritating amount of time. In my case, ModifyCode simply handles type repropagation after AdaptToInputs if the code has already been generated.
 

In some of my VIs I keep track if GenerateCode has ever been completed once and behave slightly differently if it has, so that code doesn't get re-generated all the time when it doesn't need to.  I'm guessing I could do something similar where if code has been generated I could call the ModifyCode instead for faster editing of the VI.

I also keep track of whether or not the VI has been generated and use that to trigger whether to call Modify or Generate from AdaptToInputs. I suppose having some conditional code in Generate also would have worked. I just didn't think of it, perhaps being misled by the existence of ModifyCode.