Leaderboard

Quick update: The first time I tried to run the posted code I got a crash, but now I suspect that was LV12 doing its thing and not directly related to the code. When I try it this time I actually get a quite helpful error message: This is a good start but still bugs me a little bit. When you move from the world of strict, static typing into the world of dynamic typing then you expect a lot of errors to move from compile time to run time. This is the price of doing business sometimes. What I wonder is if it is really necessary to stop everything when this happens, could this be an error you could recover from? This is mostly curiosity, I find recursion and DD to be a bit slow and avoid both as much as I can, combining the two is getting into slow-squared country, population unknown but not me. Edit: That is a great explanation by AQ, but it did not address what seemed to be happening at the time. I understand what is and is not recursive and agree it is best to wait until run-time. The OPs description was that real, honest-to-goodness recursion was happening and your reply was not a bug, that had me confused. The error window I see makes all of the difference. If the OP did not see it for some reason, ouch.

I assume from reading this that the OP is aware of recursive functions, including the prerequisite(?) reentrency settings. If I quote from the NI OOP FAQ: You can configure a dynamic dispatch member VI to allow recursion by setting it to be reentrant and to share clones between instances. I assume this means a DD VI is like all other VIs in this regard. So am I to understand that DD VIs are in fact different from other VIs and support recursion even in the absence of the usual settings for reentrency? That would be interesting, and probably very inefficient, and does seem to contradict the documentation I have come across over the years. This also runs counter to my experience (in LV). The "normal" LV recursion mechanism places a limit (32000?) on the recursion depth. I do not run out of memory in the normal case, I simply get an error message about too many nested VI calls (no crash). The fact that a do-nothing VI here called recursively runs until crashing hints (to me, at least) that it is operating outside of the normal LV recursive mechanism.