|
I made the leap from VB / VB.Net to C# about 4 or 5 years ago. Once the initial curve has been climbed, you will find that they are really quite similar. VB is just more verbose IMO, it's a perfectly good language.
The main benefit of using C# daily for me has been when dealing with other programming and scripting languages such as C/C++, PHP, Java, CSS etc as the syntax is very similar (beyond the which makes the transition between them, when required, much simpler.
Glad you're enjoying it!
|
|
|
|
|
Hello. I am new to C# programming. I am working on creating a Payroll system. I am having trouble getting my btnSearch to connect to another form when clicked. What I am trying to do is give a user the option to search for an employee by their last name and have them directed to another web page which will display the employees information. I am not sure how to make the connection from the btnSearch to a View Personnel form. I have tried looking for some examples but have had no luck. Any help would be greatly appreciated.
Thank you!
|
|
|
|
|
What platform are you working on? (ie. Webforms or MVC?) It'll make a difference on how to approach this.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
I am using Microsoft Visual Studios 2010. They are aspx.cs files.
|
|
|
|
|
Cool.
You need to create a button click handler for the button in your code behind for the page where the button is located. In that button click handler you need to do a Response.Redirect("WhereYouWantToGo.aspx"); call to redirect to the new page.
MSDN[^] article on how to do this.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Thank you Marcus! I got it working now.
|
|
|
|
|
You're welcome.
I wasn't, now I am, then I won't be anymore.
|
|
|
|
|
Suppose two strings,
String S1, S2;
Which is faster:
if( S1.ToLower() == S2.ToLower() )
Or:
if( String.Compare(S1, S2, true) == 0 )
Under what conditions might the relative speed vary?
I need a 32 bit unsigned value just to hold the number of coding WTF I see in a day …
|
|
|
|
|
Blake Miller wrote: Under what conditions might the relative speed vary?
- strings are reference-types, and atomic in memory
- Converting them both before the comparison is slower than comparing them directly (there can be only one!)
- Microsoft "advises" to use uppercase constants. Has something to do with efficiency in comparing.
- Does it matter?
The last point is the most important one; readability is important, as it influences maintainability. If you're doing a lot of string-operations, consider a RegEx for the job.
-edit;
Many string operations, most important the Compare and Equals methods, now provide an overload that accepts a StringComparision enumeration value as a parameter.
When you specify either StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase, the string comparison will be non-linguistic. That is, the features that are specific to the natural language are ignored when making comparison decisions. This means the decisions are based on simple byte comparisons and ignore casing or equivalence tables that are parameterized by culture. As a result, by explicitly setting the parameter to either the StringComparison.Ordinal or StringComparison.OrdinalIgnoreCase, your code often gains speed, increases correctness, and becomes more reliable.
It's one of FxCops' warnings[^]
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
modified 2-Nov-12 16:25pm.
|
|
|
|
|
Thank you for your answers.
Would you have a link to a tech note, language guide or MSDN about this part "Microsoft 'advises' to use uppercase constants."
It does matter. I am looking into this because customers are complaining about CPU load.
I need a 32 bit unsigned value just to hold the number of coding WTF I see in a day …
|
|
|
|
|
Modified the post to include the FxCop rule
|
|
|
|
|
Blake Miller wrote: It does matter. I am looking into this because customers are complaining about
CPU load.
I think you are barking up the wrong tree if that's the case. As another poster responded, with 1 *MILLION* string comparisons, the difference in performance is non-existant. Your performance issues are likely elsewhere.
|
|
|
|
|
The first one creates two new strings, converting each character to lower-case, and then compares the results.
The second one performs a case-insensitive comparison of each character, without allocating any new strings.
Instinct would say that the second will always out-perform the first. Here's some code to test that:
int ITERATIONS = 1000000;
string s1 = "Hello World";
string s2 = "hello world";
Debug.Assert(s1.ToLower() == s2.ToLower());
Debug.Assert(string.Compare(s1, s2, true) == 0);
var sw1 = new Stopwatch();
sw1.Start();
for (int i = 0; i < ITERATIONS; i++)
{
Debug.Assert(s1.ToLower() == s2.ToLower());
}
sw1.Stop();
var sw2 = new Stopwatch();
sw2.Start();
for (int i = 0; i < ITERATIONS; i++)
{
Debug.Assert(string.Compare(s1, s2, true) == 0);
}
sw2.Stop();
Console.WriteLine("ToLower: {0}", sw1.Elapsed);
Console.WriteLine("Compare: {0}", sw2.Elapsed);
On my computer, the output is:
ToLower: 00:00:00.4507542
Compare: 00:00:00.1856049
The ToLower approach takes more than twice as long as the Compare approach.
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Confirms my 'gut feeling' and we all know how much we like to depend upon those
I need a 32 bit unsigned value just to hold the number of coding WTF I see in a day …
|
|
|
|
|
|
Awesome! Thanks for the link.
I need a 32 bit unsigned value just to hold the number of coding WTF I see in a day …
|
|
|
|
|
In terms of application performance (rather than just statement performance.)
If you have not measured the application using appropriate data then your first step would be to do that.
If you have measured and found that this specific method containing this statement is the problem then finding a different algorithmic approach would have much more impact. The goal of course in that case is not to find a faster way to do the comparison but instead to find a way so no comparison at all is needed.
|
|
|
|
|
|
TheGermoz wrote:
has anyone experience of a working solution?
A few; didn't need one for the last years, but I've implemented Hunspell[^], NetSpell[^] and something called "iSpell", whose link I cannot find.
They worked as advertised.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
apparently they spell simply a text (I can use word?!), but I need to spell the comment in the code from VS
|
|
|
|
|
In that case, you'd need to get familiar with writing a VS-addin; I'd suggest trying to create a prototype for both "problems" (spellcheck a textbox, do something in VS), and working from there.
Bastard Programmer from Hell
if you can't read my code, try converting it here[^]
|
|
|
|
|
thanks it is a bit complicate, I was looking for a ready to run solution to do not reinvent the wheel.
|
|
|
|
|
TheGermoz wrote: I was looking for a ready to run solution to do not reinvent the wheel
Unless your wheel is better than the one of the competitor, no-one is going to look anyway. Ready-to-run solutions are known paths that are tried and validated.
"Where there's muck, there's money"
|
|
|
|
|
I have been using it for a while on several different computers, and always worked for me. Maybe you should add a Q & A (this is a tab on your link). Apparently somebody else if having problems: "It does work on VS 2010 Premium edition?? Im asking because i have it installed on VS 2010 Premium and it doesnt work"
|
|
|
|
|