|
You need to encode your text file as ISO-8859-7.
I think StreamWriter takes encoding as its parameter.
When you're alone in the Dark, Fear will protect you...
|
|
|
|
|
i just use
bt is a byte border which i encoded it
bt = System.Text.Encoding.ASCII.GetBytes(s);
s is the textbox for example
filestream.Write(bt, 0, bt.Length);
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
