|
I don't know a lot about Encoding but I think ISO-8859-7 and ASCII are not the same. Try this:
StreamWriter sw = new StreamWriter(@"C:\GreekTest.txt", flase, Encoding.GetEncoding("ISO-8859-7"));
sw.WriteLine("αβγδε");
sw.Close();
StreamReader sr = new StreamReader(@"C:\GreekTest.txt", Encoding.GetEncoding("ISO-8859-7"));
Console.WriteLine(sr.ReadLine());
sr.Close();
It worked for me. Hope help you.
Life is 5: 3 me, 1 you.
|
|
|
|
|
Hi
is it posible to make longer timeout connection ?
i'll try to wright: conn.ConnectionTimeout = 30;
buy it "Read Only" and send me an Error
how can i do it ?
|
|
|
|
|
E_Gold wrote: is it posible to make longer timeout connection ?
Connection timeout is part of the connection string. Try defining "...Connection Timeout = 60..." (60 seconds) in the connection string.
The need to optimize rises from a bad design.
My articles[ ^]
|
|
|
|
|
|
I am filling dataset from excel. But all rows are not appearing in dataset. Because I am having Numbers and characters in same column in Excel.
But In dataset I am getting only numbers in that column. So please help how can I have All rows in dataset.
Snapshot is attached with code: http://i33.tinypic.com/294nrew.jpg
Thanks.
Manoj
|
|
|
|
|
I recall there is some setting in the connection string that helps with this issue.
It is the IMEX=1 setting. Not sure if 1 was the correct value, but a few searches should present the correct answer.
http://www.connectionstrings.com/?carrier=excel[^]
xacc.ide - now with TabsToSpaces support IronScheme - 1.0 beta 1 - out now! ((lambda (x) `((lambda (x) ,x) ',x)) '`((lambda (x) ,x) ',x))
|
|
|
|
|
Thanks it is working.
strConn = @"Provider=Microsoft.Jet.OLEDB.4.0;" +
"Data Source=" + txtUrl.Text + ";" +
"Extended Properties='Excel 8.0;HDR=Yes;IMEX=1'";
|
|
|
|
|
I used several forms in my project.
I have one big problem: when I want to click the button on the non-activated form (i.e., non-current form), then I have to click two times (first time just activate the form and it works only for the second click). Actually, for most softeares we use everyday, we only need to click once even the button on the form is not activated or not current form.
I have tried several functions, but non works. I think most people will meet this problem. I really don't know how do you solve this?
thanks.
|
|
|
|
|
You can activate the form on hover.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
Which is faster? I have a class that loops through consitantly monitoring input and filters down tot he correct path based off multiple factors, I noticed now that my paths that are down the nested if by 7 or 8 layers take as long as 2 seconds to execute.
Will porting over my code to select / case statements increase efficiency?
|
|
|
|
|
I prefer if statements for non-numeric comparisons and case statements for integral comparisons of large sets. Likely the code slowness is due to algorithm inefficiency than control-flow structure as .NET uses a nifty cheat to make cases work fast on strings. Post some code.
Need software developed? Offering C# development all over the United States, ERL GLOBAL, Inc is the only call you will have to make.
Happiness in intelligent people is the rarest thing I know. -- Ernest Hemingway
Most of this sig is for Google, not ego.
|
|
|
|
|
For me, it's a matter of readability, and then suitability of purpose. Heavily nested if statements are generally harder to read than a switch statement. Unless I feel a crying need to use if (less than three nested if's), I'll use a switch statement.
"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
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
So there is no actual efficiency when using a select case over a bunch of if statements?
|
|
|
|
|
I don't know if you'd notice an efficiency using either one unless you were going to have more a handful of cases. Most of my switch statements never exceed more than a dozen cases.
"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
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
EliottA wrote: So there is no actual efficiency when using a select case over a bunch of if statements?
In your situation, there is no "actual efficiency" in terms of performance using if statements vs using switch statements. If your deepest loops are taking 2 seconds to execute, switching from if to switch may improve your execution time by the tiniest fraction of a millisecond.
But that's besides the point. Unless you absolutely need to shave milliseconds off your code, decisions about how your code is organized should be about readability and communicating your intent to future readers of the code. Don't prematurely optimize.
That aside, there is more opportunity for a compiler to optimize long switch statements than with a series of if statements. The compiler will typically convert if statements into a series of compare-and-jump operations. Switch statements (in C#) can be implemented using techniques like jump tables (when comparing ints) or hash tables (when comparing strings) to increase code efficiency. But we're talking about real low-level, behind-the-scenes stuff that the average developer will likely never have to consider in real-world applications.
Enjoy,
Robert C. Cartaino
|
|
|
|
|
A switch is implemented differently depending on how many labels there are in it. If there are more than five (IIRC) labels, it's implemented using a hash table. If there are fewer labels it's implemented using if/else tests, so the earlier labels are the fastest to reach, but when it's implemented using a hash table it takes the same time to reach any of the labels.
So, if you have more than five if/else checks on the same value, you should definitely replace it with a switch.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
It also means that if you want a fast switch statement, and you have less than five cases, pad the switch statement with do-nothing cases to get the speed gain over the if/else nest.
"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
-----
"...the staggering layers of obscenity in your statement make it a work of art on so many levels." - Jason Jystad, 10/26/2001
|
|
|
|
|
No, the if/else implementation is still faster for a switch with very few items.
Despite everything, the person most likely to be fooling you next is yourself.
|
|
|
|
|
Hi,
for or readability/maintainability the switch is best.
for performance it very much depends on the probability distribution. If one or a few cases are much more likely than all the others, use chained if/else for these cases (ordered by descending probability), then handle the remaining stuff with a switch; that way you avoid the switch overhead most of the time.
|
|
|
|
|
I've recently upgraded to Visual Studio 2008 (having used Visual Studio 2005) up until now and ran into a nasty bug which took me hours to sort out.
I've always had a config file (in XML format) which I used to store configuration settings for my apps. My convention has always been to name this file MyApplicationName.config. I've noticed that sometimes Visual Studio generates a file called MyApplicationName.exe.config but I hadn't bothered to figure out what this file is all about as it appeared to me that it wasn't always created and it didn't matter whether I include it with the release or not anyway.
Now it seems that Visual Studio 2008 uses my naming convention as opposed to adding the .exe bit in so all of a sudden my config file clashed with the one the CLR (or whoever) expected. The problem only manifested when I try to connect to a DB or a TCP port. I can easily change my naming convention so it's not a problem anymore but I thought now might be a good time to find out what this config file is all about.
Could someone point me to an article or description perhaps? I have some specific questions:
Why do I sometimes see this config file and at other times it is absent?
Could I not use the existing config file and add my config settings to it or is it best to have my own seperate config file?
|
|
|
|
|
Dewald wrote: Could someone point me to an article or description perhaps?
Sure, why not[^]
led mike
|
|
|
|
|
OK thanks. I guess I should have found it myself 
It still doesn't answer my questions though. And also it does not match what I'm experiencing here. According to the article the config file will be named MyApp.exe.config and that is what used to be the case when I used VS2005 but now that I'm using VS2008 the name is MyApp.config which clashes with my own config file that I've always used.
Moreover, even if the file isn't present (and I still don't know when to expect to see the file and when not), a call to AppDomain.CurrentDomain.SetupInformation.ConfigurationFile reveals that the name is MyApp.config and not MyApp.exe.config. What gives?
I've seen that you can add an "Application Configuration File" to your project but I have not done this. Even so, if I have my own MyApp.config file in the application directory the program crashes when I try to access a DB or TCP socket. Other applications in which I don't access DB's or sockets couldn't care less whether there is a file called MyApp.config or not.
|
|
|
|
|
Dewald wrote: and I still don't know when to expect to see the file and when not
I have no idea what that means? "when to expect to see the file", see the file? 
Dewald wrote: Even so, if I have my own MyApp.config file in the application directory the program crashes when I try to access a DB or TCP socket.
Dude, calm down, you just need to learn about config files. Don't think of them as some magic solution that you don't need to understand. Like everything else you do need to understand so take the time to learn. That article I linked to should be a place to start but there is certainly more information.[^]
led mike
|
|
|
|
|
led mike wrote: I have no idea what that means? "when to expect to see the file", see the file?
It means that I can make a call to AppDomain.CurrentDomain.SetupInformation.ConfigurationFile which gives me the name of a file, yet nowhere in the application directory does such a file exist. If the file existed I would have expected to "see the file".
led mike wrote: Dude, calm down, you just need to learn about config files. Don't think of them as some magic solution that you don't need to understand. Like everything else you do need to understand so take the time to learn. That article I linked to should be a place to start but there is certainly more information.
See, right here you've touched on what is probably the very essence of my frustration. I've been programming for close to two decades now so one would think that I'd know how to get to the bottom of new programming issues quickly. One would think that I'd know what there is to know about programming but I don't and I still get daunted by the plethora of information out there.
I made the switch to C# not too long ago and it was clear to me from the outset that it would take years to understand everything but I'm being paid to develop applications and don't have years to spend. So obviously I prioritise and get to understand the important things first. I didn't get the impression that configuration files were high on that list of important things. The fact that the book I purchased[^] (which in retrospect seems to be a pathetic book by the way) makes no mention of configuration files whatsoever may have reinforced this notion.
Then, when I run into an issue like this, I turn to the internet to see what I can learn. I started off googling for answers but when I didn't really get the answers to my questions I thought I'd turn to CodeProject. I would assume that the two links you provided should be very good for getting me underway but neither gives me any hint as to why in VS2008 I'm getting an AppName.config filename when in VS2005 I got AppName.exe.config. Every minute that I spend researching this issue is a minute that I could have spent testing other aspects of my application or writing new code and I feel guilty for spending so much of the time for which I'm being paid to develop. So what do I do? I change my proprietary file name to something that doesn't clash with AppName.config, thinking that I'll bother with getting to the bottom of that issue later (and probably never do) so I can get on with my work.
Maybe I'm just not a good developer then but seriously, how many developers are there who understand every last article in MSDN? Is that what you allude to if you say "Like everything else you do need to understand so take the time to learn". And how many other developers are there who, like me, don't have the time to exhaustively research a matter like this when they actually have a workaround for the time being and while the deadline is rushing down on them?
OK, enough venting from me  Maybe I'd have done better by using this time to research configuration files or work at meeting the deadline but this has always been something that concerned me. Am I a bad developer if I don't understand everything?
|
|
|
|
|
Dewald wrote: Am I a bad developer if I don't understand everything?
Bad is a relative term. Would one be a better developer if they actually know and understand the technology they work with? Of course. Operating in the dark will almost always result in Technical Debt[^]. One mistakenly believes they are cheating time by finishing faster, it is a mere illusion, a fantasy.
Dewald wrote: while the deadline is rushing down on them?
Ah yes, the pragmatism card. "Oh dear, a deadline, what will I do!" Let's say that digging into one topic like this one, config files, could keep a person busy for 1 or 2 maybe 3 days. At the end of that time they might not know everything, but would no longer be working with "magic". They would posses a great deal more knowledge than none. I submit that if those 2 days jeopardize a deadline, then there are far bigger problems with that project than any single developer can solve.
I will close my thoughts with one last observation. There is a significant gap between knowing nothing about a subject and knowing everything. Does not the pragmatists path lay somewhere between the two extreems?
led mike
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
