|
Can you show where you put your timing code?
There is no reason why adding to a StringBuilder should take any noticeable amount of time. I wrote a simple test function in my toy language
x:
dt←$DateTime:Now;
sb←#new $StringBuilder ⍬;
{sb:AppendLine (⍵:ToString)}¨⍳x;
($DateTime:Now)-dt
... and it can add 10,000 lines in under a second. (Most of that is to do with pushing the function in my language onto the stack 10,000 times, I think.)
Your times look quadratic. Are you calling this function (sorted.Count) times?
|
|
|
|
|
You could always use the StrCmpLogicalW function that Windows Explorer uses to sort your items.
How to use in C#: StrCmpLogicalW
Use this in an IComparer like here.
Then your StringBuilder loop should run really fast.
|
|
|
|
|
You could combne the two lines:
builder.AppendFormat("{0}\r\n", s);
".45 ACP - because shooting twice is just silly" - JSOP, 2010
-----
You can never have too much ammo - unless you're swimming, or on fire. - JSOP, 2010
-----
"Why don't you tie a kerosene-soaked rag around your ankles so the ants won't climb up and eat your candy ass." - Dale Earnhardt, 1997
|
|
|
|
|
builder.AppendLine(s); would do the trick also 
No memory stick has been harmed during establishment of this signature.
|
|
|
|
|
Since you're using readonly single-line items, I'd suggest using a ListBox. You might want to temporarily disable painting when adding multiple items.
Bastard Programmer from Hell 
|
|
|
|
|
What's missing in this scenario is information about where the strings you add newlines to are coming from.
If you are reading them in from a file, and they are delimited by newlines, that's one case: in that case you can add them to your StringBuilder as you read the file, a line at a time, taking care of delimiting with newlines right there. If it's a file, but not delimited with newlines, and you've got to parse the whole file to create the whatever semantic units that are to become "lines," that's another story. And, finally, if these strings are being created on-the-fly by you ... being calculated/composed in some way: another scenario.
If you can focus on getting the strings into a List<string>, you can just call 'Sort on that List, and then you can directly fill a TextBox by setting the 'Lines property of that TextBox (an array of string) to, courtesy of Linq, the List<string> converted to an array: as in:
List<string> sl = new List<string> { "wo", "ab", "c"};
sl.Sort();
textBox1.Lines = sl.ToArray();And all of the above, as is said in almost every answer above, should not obscure that the problem here is probably not in the speed of StringBuilder itself.
"Anyone who shows me my 'blind spots' gives me the gift of sight." ... a thought from the shallows of the deeply shallow mind of ... Bill
|
|
|
|
|
Hi All !
There are some Items in my List Box(ListBox1) include "Positive" or "Negative" items ,so when I want to add Positive , "Fore color" for this Item in list Box should be Green , and if I want to add Negative item to List Box , "Fore color" for this Item in list Box should be Red :
if (ListBox1.Items.ToString() == "Positive")
ListBox1.ForeColor = Color.Green;
else
ListBox1.ForeColor = Color.Red;
thanks for any Help !
|
|
|
|
|
That's wrong cause you set the color for the entire listbox.
The best/easiest way is to set the DrawMode to OwnerDarwVariable and handle the ListBox.DrawItem event.
There you could use any brush you like to draw the text.
Just look for listboxDrawItem on bingle and you'll find lots of examples.
All the best,
Dan
|
|
|
|
|
Have you considered the ListView as an alternative to the ListBox. When set to the 'Details' view it supports per item colouring via the ListViewItem.ForeColor and .BackColor properties.
Alan.
|
|
|
|
|
All the best,
Dan
|
|
|
|
|
Wonde Tadesse
MCTS
|
|
|
|
|
Applying different ForeColors to the items of a ListBox is pretty easy; here[^] is an article that discusses an entirely different topic, however the download will show you how to get what you want.
|
|
|
|
|
You need to either custom draw the items or have a custom control (e.g. here is one by me[^]).
|
|
|
|
|
hello guys.. I have a function in some class (actually its DAL). Now return type of this function can be either DataTable, DataSet or DataRow like this
public DataTable function(int myTableKey)
{
DataTable dt;
return dt;
}
Now if everything goes right, this function returns me the data table.
But what if some goes wrong, like if I get some exception or I wanna return some string message in case of failure. What should I do? thnx
|
|
|
|
|
Exceptions are thrown, not returned.
In the case of a user-defined failure you can choose to either throw an exception with a meaningful error message, if it's an exceptional condition that should be handled as an error, or return null from the function (obviously this should be defined in the contract for the function and calling methods should handle it appropriately).
|
|
|
|
|
But how? Here is the code to make it more clear
public DataTable function(int myTableKey)
{
string msg;
try
{
DataTable dt;
return dt;
}
catch(Exception ex)
{
msg = ex.Message;
return msg;
}
}
Now focus on the return statement in catch block. This is what I was talking about.
|
|
|
|
|
Just like said before/above either throw the exception and handle it on the calling client,
or log it, return null and check for null on client.
catch(Exception ex)
{
throw;
dt = null;
}
return dt;
I recommend throwing it and handle the exception on the client calling method.
All the best,
Dan
modified 2-Dec-11 17:16pm.
|
|
|
|
|
Unless this is a top tier interface function where exceptions are bad (and since it's doing database stuff, it shouldn't be), you should just let the exception escape, to be handled by the calling function.
|
|
|
|
|
I'd say do nothing, unless you want to do some custom exception handling in your function. Exceptions are for exceptional circumstances and in my mind there's always been little point in catching an exception just to rethrow it. The error message in an exception is often useless without the stack trace as well.
It's up to the *calling function* to decide what to do in the event of an error, so it may handle the exception there or let it pass further up the call stack.
In particular stuff like this
try
{
}
catch (Exception ex)
{
throw ex;
}
is pointless and bad as you'll lose the stack trace.
Regards,
Rob Philpott.
|
|
|
|
|
If you just use
try { ... }
catch(Exception) { throw; }
(note, 'throw' not 'throw ex'), you don't lose the stack trace. It's still pointless but at least it's not harmful.
|
|
|
|
|
Indeededoody!
Regards,
Rob Philpott.
|
|
|
|
|
I agree with allowing the Exception to be thrown. You may also add some context to the Exception if you choose:
catch (Exception ex)
{
ex.Data.Add("Method", "function");
ex.Data.Add("myTableKey", myTableKey);
throw;
}
Personally, I like to determine what type of Exception it is (timeout, deadlock, duplicate key, etc.) and wrap it in a custom Exception.
|
|
|
|
|
Thanks for a good tip, +5
Bastard Programmer from Hell
|
|
|
|
|
I hate to admit that I still don't fully understand what happens when it comes to .NET versioning.
If I want to use an Infragistics control that was compiled against the 2.0 framework, in a 4.0 project, does this cause a mix of 2.0 and 4.0 objects in the same runtime environment?
For instance, if the 2.0 control creates a new Rectangle object, is that a version 2.0 Rectangle, while my 4.0 code would be creating version 4.0 Rectangles?
Or does all the code in the process run against version 4.0 objects?
The difficult we do right away...
...the impossible takes slightly longer.
|
|
|
|
|
2.0 code would know nothing about the 4.0 code so it could only create its own version. Only one version of an assembly can be loaded into the appdomian at a time so objects created will be from that version. However, it does get a bit tricky if you use codeBase[^] or assembly rediection[^]
No comment
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
