Yeah, it's called an IDE and compiler. You have to do about the same thing in your code. Create an instance of the compiler and feed it not a string, not an object graph that represents the code you're creating. I wish it was as easy as a couple lines of code, but no. Far from it.
But, doing something like this really is not going to help you to solve your problem.
I'm so close to finishing a program I've been working on for a year and the only thing hanging me up is this damn TreeView problem. I just find it so bizarre that MS could not provide some very simple functionality to a TreeView, that I would think would be self-evidently obvious properties and methods to include straight-away. I come up with nifty solutions only to have them dashed by a lack of really basic control methods. So frustrating.
Not so useful. Actually, pretty limiting in both security and performance.
First, it's poor-performing code as it has to be compiled before use, at runtime. Access to variables might also have to be done through reflection as you REALLY don't want to run this code in the same AppDomain as the application code because of HUGE security problems with running user-enterable code in an app. Google for "SQL Injection attacks" for examples on how bad this is. The compile-time compiler also cannot possibly predict the contents of a string so it cannot pre-compile anything, wasting more time. You MIGHT get away with a caching scheme to improve performance a little bit, kind of like how strings are stored, but again, you'd have to be able to store the string with the compiled code so you have a quick lookup of the string version of the code as a key.
Oh, and you also lose type-safety and Intellisense.
If you think you need to do this in your application code, it's generally taken as a sign your code design is DEEPLY flawed.
Good points. So the emphasis is back to the limitations of the .Nodes() property. What a shame they did not set it up as, for example, TreeView1.Nodes(NodesArray(x)).SelectedNode. That would be a perfect road map for the Nodes property to follow, to get to a destination in the tree.
That doesn't make sense either as you'd have to manually walk the tree to find the node that is selected. Not very efficient, is it??
The TreeView already has a SelectedNode property which will return the node that is selected. From there, it's trivial to navigate up to the Node tree to the root of the Nodes collection in the TreeView control.
Getting back to your original search problem, you're going about it wrong. You're thinking about searching a tree structure that's not designed to be searched efficiently.
What you should be doing is a dedicated indexing solution for a collection of paths, each of which contains a reference to the Node it came from. Searching the dedicated structure would be far more efficient then searching the TreeView Nodes collection.
TnTinMn offered the following solution back in post, 13 May '13 - 13:13. Seems pretty darn elegant and compact. I am in the process of testing its performance on a TreeView loaded with a huge drive's directory structure.
Something like: Find( CurrentNode, SubPath ) where the CurrentNode and SubPath are adjusted on each call to itself.
That is easy in principle, but it does not appear that there is any way to tell vb.Net to restrict a Find() to a starting childnode and a sub path. Without that, recursion is useless. Unless I keep building a new node structure that omits the prior part already searched. If that node structure represents an entire harddrive, that would be slower than watching mountains grow.
That is where the frustration is. There is no way to set any ARBITRARY node as a "current" node and start the search from there, in a Find() method. Although you can restrict the search to a node and none of its children, you can't programmatically start a search at any node without it being specific. There is no general statement for: = MyNodes(2).Nodes.Find("Hello", True)
and = MyNodes(2).My1stChildNodes(3).Nodes.Find("Hello", True)