|
treddie wrote: I am having zero luck finding anything on doing a TreeView1.Nodes.Find() starting from a particular child node.
Don't trust on luck. Where's your code?
treddie wrote: Find() apparently works over the entire tree, and does not let you specify a starting point in the tree.
Trying something like below?
Imports System.Windows.Forms
Module Module1
Private TreeView1 As New TreeView()
Sub Main()
Using f As New Form
Dim btn As New Button
btn.Dock = DockStyle.Top
Dim node1 As TreeNode = TreeView1.Nodes.Add("Node1")
node1.Nodes.Add("Sub1", "Sub1").Nodes.Add("Hello", "Hello")
Dim node2 As TreeNode = TreeView1.Nodes.Add("Node2")
node2.Nodes.Add("Sub1", "Sub1").Nodes.Add("Hello", "Hello")
Dim foundNodes As TreeNode() = node2.Nodes.Find("Hello", True)
If foundNodes.Length > 0 Then
TreeView1.SelectedNode = foundNodes(0)
TreeView1.Focus()
End If
f.Controls.Add(TreeView1)
f.Controls.Add(btn)
f.ShowDialog()
End Using
End Sub
End Module
Bastard Programmer from Hell 
If you can't read my code, try converting it here[^]
|
|
|
|
|
Hey, Eddy.
I probably should have put this post in my other thread, since I thought I was asking a separate question, but it turns out, I'm back to the old topic! 
The problem I see with that solution is that it assumes that you know that the answer lies somewhere beneath Node2 and not Node1. In fact, if you don't know, then you either have to
'
1). Search the whole tree and find all instances of "Hello", then look at the full path property to see if it matches a pre-defined path, or
'
2). You have to be able to step through each node with Find(), and searchAllChildren = "False", to prevent the search from going any deeper than one node at a time. It also has to reject any instances of the search name that might occur ABOVE the current node. In the latter case, as far as I can tell, you need to be able to set a child node as a current node, as if it was the parent node so that the search starts from there. But vb.Net offers no way to set a child node to "Current" during a Find().
UPDATE:
If I change your code to the following:
Dim MyNodes(2) As TreeNode
MyNodes(1) = TreeView1.Nodes.Add("Node1")
MyNodes(1).Nodes.Add("Sub1", "Sub1").Nodes.Add("Hello", "Hello")
MyNodes(2) = TreeView1.Nodes.Add("Node2")
MyNodes(2).Nodes.Add("Sub1", "Sub1").Nodes.Add("Hello", "Hello")
Dim foundNodes As TreeNode() = MyNodes(2).Nodes.Find("Hello", True)
If foundNodes.Length > 0 Then
TreeView1.SelectedNode = foundNodes(0)
TreeView1.Focus()
End If
I gain flexibility in how the parent node is defined, but there is still no flexibility in the Find() operation...If instead of:
= MyNodes(2).Nodes.Find("Hello", True)
'
I want to do:
= MyNodes(2).My1stChildNodes(3).Nodes.Find("Hello", True)
I have to set that up explicitly. And it does not seem to be a problem that lends itself to recursion. The only option then, is to set up separate Find() functions for each node depth you want to start at. For a harddrive's directory structure, that could end up being 10-20 separate functions, easily.
modified 12-May-13 6:13am.
|
|
|
|
|
treddie wrote: is that it assumes that you know that the answer lies somewhere beneath Node2 and not Node1. In fact, if you don't know, then you either have to
If it's a path, then you'll know where it's located. If it's a random property, you'll have to go and check each item.
treddie wrote: I want to do:
= MyNodes(2).My1stChildNodes(3).Nodes.Find("Hello", True)
TreeView1.Nodes("Node2").Nodes("Sub1").Nodes.Find("Hello")What are you trying to do? This way of solving does not seem to be very helpful/fruitfull
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
The basic problem is this. In vb6 (and the COM controls as they were carried over into .Net), you have Dir and File List boxes. You could double-click a folder or file name and do something with it. You can do the same thing with a TreeView. The problem starts when you want to save out those selections when you close the program, so that when you come back, the Treeview has the old selections intact. That was no problem with a Dir or file Listbox, because you could simply set the boxes to a desired path name.
The question that comes up might be, "Well, why not stick to using Dir and File ListBoxes, then?" I wanted to do just that to simplify my port-over to vb.Net, and that would have been fine...If not for the fact that Dir/File Listboxes cannot pass the MAX_PATH = 260 barrier. Another problem in vb6, is that the ListBoxes are not Unicode compatible. But even though they are in .Net, the MAX_PATH barrier is still insurmountable.
So, the TreeView is the "only" answer. But there is no way to tell a TreeView to select a given node based either on a fullpath (there is no option for this), or to tell it to go to a particular node index or node handle. The only option is to store the node sequence (like, "1, 3, 2, 7") and count how many child nodes that translates into (4), then go to a sub or function that explicitly utilizes that same amount of nodes, (Nodes(1).Nodes(3),Nodes(2).Nodes(7)) in one or more methods. Now, in my 1/2 hour quick check of folder depths on my c:\ drive, I counted a maximum folder depth of 12, so it could easily be over that amount. That means, bare minimum, I would need 12 separate subs (These are quicky examples, and not debugged):
Private Sub 1Node (ByVal ChildNodes() as Integer)
TreeView1.SelectedNode = TreeView1.Nodes(x)
TreeView1.SelectedNode.Expand()
End Sub
Private Sub 2Nodes (ByVal ChildNodes() as Integer)
TreeView1.SelectedNode = TreeView1.Nodes(x).Nodes(y)
TreeView1.SelectedNode.Expand()
End Sub
Private Sub 3Nodes (ByVal ChildNodes() as Integer)
TreeView1.SelectedNode = TreeView1.Nodes(x).Nodes(y).Nodes(z)
TreeView1.SelectedNode.Expand()
End Sub
And on and on for at LEAST 12 subs. Now, you just know many people will have folder depths much larger than that (And my drives might, too), so where do you stop? 20 subs? 30 subs? 100 Subs?! I would think to be on the safe side and throwing in a safety factor of 3, a bare minimum of 60 Subs. That is hardly elegant, but if that is what I need to do, then that is just the way it is.
I have noticed a very irritating side-effect of all this...Whenever I have a commercial program that uses a TreeView to navigate a media, it never remembers your last selections. So you have to go back every time and reselect everything. Now I know why. So, it was someone here who had made the comment with reference to another thread that has a bearing on this, and I respectfully paraphrase, "...You don't really need that abilty." I NEED IT! . And I have noticed a fair number of other threads on different sites where this problem comes up with no solution. Vb.Net's quantity of properties may be on the heavy side, but the way I look at it, this is one that just really needs to be added, maybe as an overload.
|
|
|
|
|
..... But there is no way to tell a TreeView to select a given node based either on a fullpath (there is no option for this)
So what is preventing you from writing a routine to do this? It is not that hard.
Private Function NodeFromPath(ByVal path As String, ByVal tv As TreeView) As TreeNode
NodeFromPath = Nothing
Dim parts() As String = path.Split(New String() {tv.PathSeparator}, StringSplitOptions.None)
Dim nodes As TreeNodeCollection
nodes = tv.Nodes
Dim found() As TreeNode
For Each part As String In parts
found = nodes.Find(part, False)
If found.Length = 0 Then
Return Nothing
Else
NodeFromPath = found(0)
nodes = NodeFromPath.Nodes
End If
Next
End Function
|
|
|
|
|
JEEZ! That's exactly what I was trying to do! I could not find any references to anything like NodeFromPath, which would have been a huge timesaver there, alone! And with my relative newness to vb.Net, don't think I would have discovered the syntax you used for "Dim parts()" for a very long, long time.
I must confess this one had my head all fouled up.   
Sorry, I could not find an emoticon for red-faced.
|
|
|
|
|
treddie wrote: So, the TreeView is the "only" answer.
Search CP, and you'll find that a lot of people think something similar.
treddie wrote: so where do you stop?
The moment I recognize the repeating pattern; same code, same handler, just a different level. Neat piece o' code that TnTinMan posted, mine would have been longer
Bastard Programmer from Hell
If you can't read my code, try converting it here[^]
|
|
|
|
|
Eddy Vluggen wrote: Search CP, and you'll find that a lot of people think something similar.
Well, at least I'm not alone.
Eddy Vluggen wrote: The moment I recognize the repeating pattern; same code, same handler, just a different level. Neat piece o' code that TnTinMan posted, mine would have been longer
Problem is I couldn't find a way to generalize the repeating code. I looked all over for something to do just that and continued to try to solve it, but my unfamiliarity with the TreeView properties bit my ass. That really is a nice compact piece of code.
After looking at it, it seems that what makes it work, is that once each match is made, what is important is the handle of the node. Otherwise, since two nodes can have the same name and text label, there would be no way for vb to know what node was being referred to. But the handles are all different. I tried working with the handles earlier, but could not find a way to get a node selected based on its handle.
modified 14-May-13 18:14pm.
|
|
|
|
|
Hi,
I'm playing around with encryption in vb.net. The passphrase that I use is stored in code. After building the app the passphrase is not visible anymore. But with the tool CodeReflect.NET I can find the passphrase again. How should I store the passphrase in a safe way?
Cheers,
Frank
|
|
|
|
|
have a look for c# DPAPI - in short, you generate/use a machine key and iirc, use that to encrypt your passphrase - to store in a config file or such - it can only be decrypted on that specific machine (again, iirc)
its not fool proof of course(*) - but its better that storing information in cleartext
(*) what I mean is, is you should protect your machine from unwanted access
'g'
|
|
|
|
|
Hmm, I think my post was incomplete. For the application (installed on more than 1 pc) that I'm building I would like to encrypt passwords that are stored in a SQL database. I thought that I could do this via encryption. So how and where is the best option to store the passphrase?
Cheers,
Frank
|
|
|
|
|
frankelman wrote: SQL database
what flavour DB are you using ?
frankelman wrote: I thought that I could do this via encryption
yes you can, but some databases have build in column encryption which could make life easier
frankelman wrote: So how and where is the best option to store the passphrase
there's never a fool-proof way to do this - eventually, something is going to have to get the passphrase from somewhere and use it to decrypt the data, which is an exposure risk - depending on what your SQL provider supplies, you could use an algorithm written in plsql/an external function/? that generates a machine-id to use as a secret/passphrase for example - then you could do something like
insert into table(x,y,z) values (x,y,encrypt(z,getpassphrase));
where getpassphrase is the plsql function that knows how to get or build the passphrase
Or, have a control table and store the passphrase base64 encoded or simply ceasar ciphered so its not obvious - we dont know your situation, so saying what the risks are and how to mitigate against them is hard
'g'
|
|
|
|
|
Currently I'm using MSSQL2008R2. I'll have a look at column encryption. But I also realize that my application does not contain very secret data, the password is the only thing I want to encrypt.
Cheers,
Frank
|
|
|
|
|
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)<br />
Nodes(0).Nodes(x)<br />
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 vb.Net code?
|
|
|
|
|
I think you need to look at a recursive method. That is, a method that calls itself.
Something like: Find( CurrentNode, SubPath ) where the CurrentNode and SubPath are adjusted on each call to itself.
You should be able to find boatloads of examples on here, so I won't go into any more detail.
|
|
|
|
|
I was thinking about recursion, but I could not find a way to get the node depth to "recurse". Until just now maybe (lightbulb). But have to see if it is sound.
But I am still curious about my original question...Has someone found a way to turn text into code?
|
|
|
|
|
You don't need it.
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.
|
|
|
|
|
Bummer. 
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.
|
|
|
|
|
Just because it's a "simple" method to make your job easier, doesn't mean it's a good thing to put into the framework.
The .NET Framework is already too heavy. That's why it has been split into Full and Client Profile versions. Why put more stuff into it that's really not neccessary?
|
|
|
|
|
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.
|
|
|
|
|
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.
|
|
|
|
|
NeverJustHere wrote: 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.
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
