1

I have a weird problem. I want to write the visible textBox.Text to an "ini" file on FormClosing (right before the form shuts down), so I double clicked that event under the main form's Properties panel and filled the associated function as follows:

    private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
    {
        // store the whole content in a string
        string settingsContent = File.ReadAllText(settingsPath + "CBSettings");

        // replace a name with another name, which truly exists in the ini file 
        settingsContent.Replace(userName, userNameBox.Text);
        
        // write and save the altered content back to the ini file
        // settingsPath looks like this @"C:\pathToSettings\settingsFolder\"
        File.WriteAllText(settingsPath + "CBSettings", settingsContent);
    }

The form starts up without a problem, but it won't quit by clicking the x button. It only closes correctly when I comment the File.WriteAllText line out. If I just stop debugging, the files content doesn't change either.

EDIT :

The actual problem was the function which I used to find and return the userName from the ini file:

    public static string GetTextAfterTextFromTextfile(string path, string file, string fileExtension, string textToLookFor)
    {
        string stringHolder;
        StreamReader sr = File.OpenText(path + file + fileExtension);
        while((stringHolder = sr.ReadLine()) != null)
        {
            if(stringHolder.Contains(textToLookFor))
            {
                return stringHolder.Replace(textToLookFor, "");
            }
        }
        sr.Close();
        return "Nothing found";
    }

The content of the ini file:

User Name = SomeName

Bot Name = SomeName

I copied the above function from stackoverflow. I was sure that it worked because it captured 'SomeName' just as I wanted. Now I use another function (also from stackoverflow), that searches the ini file for 'User Name = ' and returns the text that comes right after it.

    public static string GetTextAfterTextFromTextfile(string path, string textToSkip)
    {
        string str = File.ReadAllText(path);
        string result = str.Substring(str.IndexOf(textToSkip) + textToSkip.Length);
        return result;
    }

The problem is, that it returns

SomeNameBot Name = SomeName

Any hint on how to limit string result to only one line? Many thanks in advance!

Community
  • 1
  • 1
betaFlux
  • 183
  • 1
  • 3
  • 12
  • Are you sure it's not throwing an exception? For example, that it looks like you're trying to save to a folder rather than a file? – Matthew Haugen Sep 13 '14 at 08:05
  • 1
    I don't see an extension in your file name.Btw, look into try / catch.Then maybe you can get meaningful error messages instead of a frozen window. – Selman Genç Sep 13 '14 at 08:05
  • Nope, no Error at all and it's not frozen, it just doesn't react to the x button click and thus doesn't save anything ot the file. – betaFlux Sep 13 '14 at 08:08
  • try to store the new replaced contents in separate string, since string is immutable. By your current coding replaced contents will not reflect in new file. – Sivakumar Sep 13 '14 at 08:28
  • I tried to use StreamWriter instead, but it also doesn't work, because of the line "streamWriter.Write(path)". I really have no clue what to do. – betaFlux Sep 13 '14 at 08:29
  • You read file from `TextProcessor.settingsPath`, but write it to `settingsPath` - don't know if it's the same value. Also, this line `settingsContent.Replace(userName, userNameBox.Text);` won't actually change `settingsContent`, so resulting file will always be unchanged – Lanorkin Sep 13 '14 at 08:31
  • @Lanorkin: You're right, I deleted the TextProcessor part earlier but forgot one, which should be gone now. As for the Replace function, I don't understand how to actually change the file content. What would I have to do? – betaFlux Sep 13 '14 at 08:44
  • `var newContent = settingsContent.Replace(userName, userNameBox.Text); File.WriteAllText("destn_path", newContent);` – Sivakumar Sep 13 '14 at 08:46
  • Thanks Sivakumar, it almost works, now there is another mysterious problem. It's all about a file called CBSettings.ini and if I try to write to it, the form won't close. If I write to "CBSettings" (without the ".ini" extension), at least a "Type" file is created, with the correct content in the correct folder. I am confused. Does Windows Forms not support ini? – betaFlux Sep 13 '14 at 09:01
  • Winforms support .ini format. Can you post your destination path? – Sivakumar Sep 13 '14 at 09:17
  • I combined path + file, but the problem persists. `public static string settingsPath = @"C:\MyWinform\CBSettings.ini";` – betaFlux Sep 13 '14 at 09:31
  • For test purpose, try to read a file from other than C directory where you have both read and write privileges and write it in same directory where you reading it. – Sivakumar Sep 13 '14 at 09:41
  • Doesn't change anything, but still thanks for the suggestions. I'll have a look at my custom methods that I use to read the file and declare the userName variable in the first place. Something must be awfully screwed up. – betaFlux Sep 13 '14 at 09:59

1 Answers1

3

This is a normal mishap on the 64-bit version of Windows 7, caused by a nasty flaw in that operating system's Wow64 emulator. Not limited to Winforms apps, C++ and WPF apps are affected as well. For .NET apps, this only misbehaves if a debugger is attached. Repro code:

private void MainForm_FormClosing(object sender, FormClosingEventArgs e)
{
    throw new Exception("You will not see this");
}

The debugger won't stop when the exception is thrown and you can't close the window anymore. I wrote a more extensive answer about this problem, including recommended workarounds, in this post.

Quick fix in your case: use Debug + Exceptions, tick the Thrown checkbox. The debugger now stops when the exception is thrown, allowing you to diagnose and fix your bug.

Community
  • 1
  • 1
Hans Passant
  • 922,412
  • 146
  • 1,693
  • 2,536
  • 1
    Woooooooot, this is huge,very useful to know. – Matthias Müller Sep 13 '14 at 10:32
  • Yes thank you, very helpful indeed, but there was actually another reason for my problem. I updated my question. – betaFlux Sep 13 '14 at 16:54
  • Well, sure, once you know how to revive the debugger then it is simple to find the real bug, isn't it? Did you downvote this post? – Hans Passant Sep 13 '14 at 17:05
  • Now wouldn't that be stupid? No Hans, I did not downvote your post, in fact I tried to upvote it but my reputation score is too low. And I didn't even revive the debugger, I just changed the way the file is read, but still without any success. – betaFlux Sep 13 '14 at 19:10