Converting a string into a method
-
Only because it has such far reaching and useful consequences. I doubt that .Net will cease to grow and get even more heavy, but this option would serve so many uses where recursion is not an option.
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.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Eddy Vluggen wrote:
Ano node contains a node-collection that can be searched. If you know what node to start from, that is.
Eddy, is that a product?...The only thing I found was a site called "Ano Node", a freenet help site.
That should have been "A node contains a Nodes collection...".
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
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.
A guide to posting questions on CodeProject[^]
Dave KreskowiakGood 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 should have been "A node contains a Nodes collection...".
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
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.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
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.
A guide to posting questions on CodeProject[^]
Dave Kreskowiak -
Hi again. I have a peculiar problem that is somewhat reminiscent of vb6's Eval() function. Let's say I have a TreeView populated with an entire harddrive's directory structure, and I want to select the node that contains a folder I am looking for. If I use the .Find method, the search could take forever, and I may end up with multiple places in the TreeView where this name is located. If I already have the full path to the correct folder, then I need a quick way to get to the node without having to search the entire tree. Now, I actually have a quick way of doing this (at least I am confident it will work), but in the process of getting to that solution, I was experimenting with another idea that harks back to that vb6 Eval() function...Sort of. That other idea revolved around selectively expanding a tree branch and testing inside each child node to make sure that the next folder name in my full path could be found there. If so, it would expand that node and continue until all folders in the full path had been exhausted. Theoretically, I would then be at my desired node, which I could then select in the tree. But the problem is that in order to do that, you start at TreeView1.Nodes(0) and do a Find(). Once that node is selected, it gets expanded and you then do a Find() for the second folder, which gets found at Nodes(0).Nodes(x). Moving along in the same fashion, you get to Nodes(0).Nodes(x).Nodes(y), and so on till the task is completed. I think you can see the problem already...Without explicitly setting up Case blocks or If/Else blocks to handle each succession of methods,
Nodes(0) Nodes(0).Nodes(x) Nodes(0).Nodes(x).Nodes(y),...there is no way for the code to handle this problem. And such a folder could lie at the tenth childnode, maybe even the twentieth, or more. The point being, it is a kludge to try to estimate when you should stop providing hard-coded cases and pray that some scenario doesn't exceed that limit. That is when I was thinking if there was a way to build a string programatically to whatever length I needed it to be, like,"TreeView1.Nodes(0).Nodes(x).Nodes(y).Expand"and then convert that string into an actual code statement by having the string "evaluated" as such. Is this possible? As I stated above, I think I found another very elegant solution to my TreeView Find() problem which is simple and quick. But I am curious now, if vb.Net has the ability to turn a string into a code statement, or maybe even multiline text into actual vIf the user is going to change large parts of the code, use a
ScriptControlCOM component. It allows you to run a String as code. -
If the user is going to change large parts of the code, use a
ScriptControlCOM component. It allows you to run a String as code.