|
I f you take a look at C# File Browser[^] you will see that it contains a TreeView that displays folders, so studying the code might help you to get part way to your objective.
If that is a bit difficult to understand (you do say that you are a C# newbie) this[^] might be simpler.
For getting images to represent your files, you might also find Get Registered File Types and Their Associated Icons in C#[^] useful.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
thanks your help!
i just do with the tree with only "node contains text"( to studying) i dont want to make a file browser. Can you give me a bit of code, to do the problem above with the "node contain text"?
|
|
|
|
|
But your original question referred to checking for the existence of the folders and *.mp3s. What better way to do that than by walking the directory structure and adding only folders that contain files of interest (and the files themselves of course).
If you are doing something else, perhaps if you can explain what your app is trying to do and how you would like it to work, someone might be able to help you.
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
your detail you gave me is very useful for me to study more.
but
i just want to examine the tree bases on the node's text.
and i did it,yeaz.
here is my code:
TreeNode nodeTemp = node1.Nodes.Find(temp[0].ToString(), true);//temp[] is an String Array
if (nodeTemp.Length == 0)
{
TreeNode node2 = new TreeNode();
node2.Name = "Hello!";
node2.Text = "Hello!";
node1.Nodes.Add(node2);
}
But i have a problem with node's text display in TreeView screen:
if i assign the Text of node is:"Hello!" but it is displayed in screen:"!Hello"
what's wrong for me!
|
|
|
|
|
Firstly, well done for resolving your original problem.
silva103 wrote: if i assign the Text of node is:"Hello!" but it is displayed in screen:"!Hello"
I have never seen this behaviour before. I have had a quick play with a TreeView with a node set the same as yours and I cannot reproduce this.
The only thing that I can suggest is that you select your TreeView in the designer and examine the properties in the Properties Window. Take particular note of anything in bold as this means that the property is set to something other than its default. Try changing those, one at a time, to see if it puts things right. If you do find something please post it, as I would be very interested to know what the cause was.
If you cannot find a solution and nobody else is able to help, I would suggest that you post this as a new question, give it three hours, or so first though, otherwise people will complain at you. If you do have to ask again, mention that you asked earlier but got no help and mention what else you have tried to resolve the problem.
BTW: I am not sure about using punctuation marks in the names that you give to things ("Hello!", perhaps something like "HelloNode" would be better.). It seems to work OK this time, but is likely to bite at some time or other.
In the mean-time I am going to have a google and if I find any clues, I will get back to you.
Good Luck!
Henry Minute
Do not read medical books! You could die of a misprint. - Mark Twain
Girl: (staring) "Why do you need an icy cucumber?"
“I want to report a fraud. The government is lying to us all.”
|
|
|
|
|
|
Hello
I just want to split a string
String a = "this is a simple_sebastian_task";
I want to split it into two seperate it into two like "this is a simple" & "task"
Any clue would be appreciated
Thanks
Sebastian
|
|
|
|
|
Use String.Substring or String.Split method. Choice depends on the way you want to break the string.
It's not necessary to be so stupid, either, but people manage it. - Christian Graus, 2009 AD
|
|
|
|
|
You have given a subject of 'String split' but could not find the string.split method?
I feel I should give you the code so you don't mess it up...
string[] newStrings = "this is a simple_sebastian_task".Split(new string[]{"_sebastian_"}, StringSplitOptions.RemoveEmptyEntries);
Life goes very fast. Tomorrow, today is already yesterday.
modified on Friday, October 23, 2009 8:53 AM
|
|
|
|
|
Hello,
I have got the solution by using INDEXOF and SUBSTRING... but now I think this is the best method..
Thanks for the help
|
|
|
|
|
So this was a SQL question all along?
|
|
|
|
|
I have a manager class that is responsible for controlling a whole bunch of ports. Each port can only exist once so it's constructor is internal and used by the manager class only. This is a class library so I have no control how it will be used in any consuming application. It is critical that every port is closed at the end of the application so I have provided a CloseAll method. I can implement IDisposable but if Dispose or CloseAll isn't called it could have severe consequences that I'd like to avoid instead of saying you MUST call one of these methods.
The obvious solution is to use the destructor to call CloseAll or Dispose . I have experimented with various implementations using a static manager class, making the manager class a Singleton etc but none were reliable, I assume because the order of destruction of objects cannot be predicted, so CloseAll could be trying to close port instances that have already been GCed.
The sketch code below however seems to work 100% reliably (I have tried this in the full 'real' code with no problems too) and the destructor always gets called - and before any ports are collected. Perfect - but what I can't work out is why! Can anyone shed any light?
using System.Collections.Generic;
class Program
{
static void Main(string[] args)
{
Manager.Ports[0].Open();
}
}
public class Manager
{
private static List<Port> ports;
private static Manager manager = new Manager();
static Manager()
{
Initialize();
}
private Manager()
{ }
~Manager()
{
CloseAll();
}
public static IList<Port> Ports
{
get { return ports.AsReadOnly(); }
}
public static void CloseAll()
{
foreach (Port port in ports)
port.Close();
}
private static void Initialize()
{
ports = new List<Port>(1);
ports.Add(new Port());
}
}
public class Port
{
internal Port() { }
public void Close()
{
}
public void Open()
{
}
}
|
|
|
|
|
One way to handle this would be to add a Closed event to your Port class, and handle it in the manager. When you receive a Closed event, remove the relevant item from your list of ports.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I'm already doing that in the real code actually Pete, the issue was if Close wasn't called either on the individual Port s or on the Manager I needed to do it automatically before the Port instances are collected.
My code works, but I don't understand why. For some reason, the static manager I have created inside the Manager class always has it's destructor called before any other objects in there. Exactly what I need, but I'd like to understand why before relying on the behaviour.
|
|
|
|
|
Probably because you've got strong references in there, and there's nothing to release them until you have dereferenced them in the Manager class.
"WPF has many lovers. It's a veritable porn star!" - Josh Smith As Braveheart once said, "You can take our freedom but you'll never take our Hobnobs!" - Martin Hughes.
My blog | My articles | MoXAML PowerToys | Onyx
|
|
|
|
|
I don't think this is quite it. He never does 'dereference' them in the Manager class. AFAIK, the GC doesn't say that there are no references to the object, just that there are no reference chains back to one of the "root" objects. That is why the lack of strict ordering of finalizers is such a big deal; it is entirely possible that they could clean up the Ports first.
|
|
|
|
|
Gideon Engelberth wrote: it is entirely possible that they could clean up the Ports first
That's what I thought would be the case, but in practice it seems not. Somehow, creating an instance of the Manager class within the class seems to force finalization of that before any other references it may hold, which means I can always access them from the Manager 's destructor.
|
|
|
|
|
Hmmm... possibly. The fact that they are static probably creates that situation, but I'm struggling to work out why the private static manager instance I create always gets it's destructor called first. It must be to do with the fact that it resides within the manager class itself so somehow it prioritises that
Dave
"My code works, but I don't understand why!" - DaveyM69 (Me) BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
You can add another quote to your sig:
"My code works, but I don't understand why." - DaveyM69
made me chuckle anyways.
...cmk
The idea that I can be presented with a problem, set out to logically solve it with the tools at hand, and wind up with a program that could not be legally used because someone else followed the same logical steps some years ago and filed for a patent on it is horrifying.
- John Carmack
|
|
|
|
|
It's the first time I've found myself in this situation - honest!
|
|
|
|
|
Done!
Dave
"My code works, but I don't understand why!" - DaveyM69 (Me) BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|
|
I'd say you are getting lucky.
It seems to me that you have the finalizer in the wrong place. The Manager does not directly own any unmanaged resources. Since the Port class does directly own the unmanaged resources (from the way you describe it), it should be Disposable and have a finalizer that calls Dispose(false) as per the Dispose pattern. Then it does not matter what order things get finalized in by the GC. Port would look something like this:
public class Port : IDisposable
{
~Port()
{
Dispose(false);
}
public void IDisposable.Dispose()
{
Dispose(true);
GC.SupressFinalize(this);
}
private bool alreadyDisposed;
protected void Dispose(bool disposing)
{
if (!alreadyDisposed)
{
if (disposing)
{
}
alreadyDisposed = true;
}
}
public void Close()
{
Dispose();
}
}
|
|
|
|
|
There are no unmanaged resources held by any class (although the Port class does call unmanaged functions). Each port must be reusable and when called from elsewhere, the same object must be retrieved so unfortunately implementing the dispose pattern doesn't solve the issue I was faced with.
Thanks anyway
|
|
|
|
|
Hi Dave,
First of all I'm no expert on destruction; I've read several articles about it, and find it difficult to grasp.
My initial comments on your code are:
1. I thought one wasn't supposed to write finalizers/destructors; instead one should provide a Dispose(bool) override.
2. I am pretty sure the GC does not finalize anything when an application exits; it does when things got collected, which only happens when a new need for memory cannot be solved without it;
3. The one Manager object you create sits in a static member of class Manager, so it never dies.
4. both (2) and (3) seen sufficient to say: I can't believe CloseAll() gets called automatically.
5. There is an Application.Exit event which I believe should be the key to solving your problem.
Some more thoughts:
6. The ports keep adding to your list, even when they got closed. And they may appear more than once.
7. I would avoid managers (I generally do!) and add overall port functionality to the Port class itself, using statics (as you have in Manager anyway).
In summary:
(A) I would fire your Manager and use Application.Exit to execute Port.CloseAll()
(B) I wouldn't say "I don't know why it works", my feelings are "I am surprised it would work as is".
Cheers.
Luc Pattyn
I only read code that is properly indented, and rendered in a non-proportional font; hint: use PRE tags in forum messages
|
|
|
|
|
Luc Pattyn wrote: one should provide a Dispose(bool) override.
I agree, but then in the finalizer we would call Dispose(false); which would execute the same code so no real difference.
Luc Pattyn wrote: GC does not finalize anything when an application exits; it does when things got collected, which only happens when a new need for memory
Again, I was under the same impression, but my isolated tests seem to imply that isn't necessarily the case as it has got called every time without fail.
Luc Pattyn wrote: The one Manager object you create sits in a static member of class Manager, so it never dies.
Again, that's what I assumed. With it, the finalizer gets called, without it doesn't
Luc Pattyn wrote: Application.Exit
As this is a class library that will be consumed elsewhere I have no access to the Application object so although it would be ideal it isn't an available solution (I'll double check this tonight).
Thanks for your input as always Luc. The comments above seem negative but they are not intended that way!
Dave
"My code works, but I don't understand why!" - DaveyM69 (Me) BTW, in software, hope and pray is not a viable strategy. (Luc Pattyn) Why are you using VB6? Do you hate yourself? (Christian Graus)
|
|
|
|