views:

195

answers:

2

Hey Guys. I'm developing a small POS for a university proyect. I have a form who acts as a POS main window, with a datagrid and so on. Also, i have one form who is the Sensitive search or Incremental search, and i want that form to, select one item in a listbox and return it to the main window. Now i have a property in the main wich gets that item as a string, and when the user clicks the OK button on the search form, i want to set that property on the main window. Everythings works great except one thing: when I try to access listBox_Codigo.SelectedItem.ToString(); the app tries to dispose and closes all windows... Anybody knows Why??? I just need the selected string in that listbox and set it to the main window like this:

var Principal = (PDQ.Cajero)this.ParentForm;
                Principal.CodigoInsertado = listBox_Codigo.SelectedItem.ToString();
                this.DialogResult = DialogResult.OK;
                this.Close();

where PDQ.Cajero is the main form, who calls this form. Thanks in advance UPDATE: I just finished debuggin it, and rigth after the program gets to listBox_Codigo.SelectedItem.ToString(); the program jumps to Dispose();

UPDATE 2 This is my complete method:

private void button1_Click(object sender, EventArgs e)
    {
        if (listBox_Codigo.SelectedItem == null)
        {
            if (MessageBox.Show(this, "No se puede ingresar un producto sin seleccionarlo.\n ¿Desea intentarlo de nuevo, o Salir?", "Error", MessageBoxButtons.RetryCancel, MessageBoxIcon.Exclamation) == DialogResult.Cancel)
            {
                DialogResult = DialogResult.Cancel;
                this.Close();
            }
        }
        else
        {
            var Principal = (PDQ.Cajero)this.ParentForm;
            Principal.CodigoInsertado = listBox_Codigo.SelectedItem.ToString();
            this.DialogResult = DialogResult.OK;
            this.Close();

        }
    }

So the problem is not if the value is null

+3  A: 

There likely is no SelectedItem (meaning that the value of the property is null). In this case your code is throwing a NullReferenceException, since you can't call a function on a null reference. Because you aren't catching it, the application is catching it at a higher level an attempting to exit. This is what's calling your Dispose method.

Adam Robinson
Oh Okay. Looks like this fix it... Sorry for not seeing it at first... Thanks Guys
josecortesp
If this fixed your problem I'd appreciate it being marked as the answer. Thanks!
Adam Robinson
+1  A: 

I would guess that the form is disposing because you aren't handling a NullReferenceException.

My general rule of thumb for exception handling in GUIs is to have a try-catch block in all the event handlers that logs the exception to a file and notifies the user of an error.

What do you get with this code?

private void button1_Click(object sender, EventArgs e)
{
    try
    {
        if (listBox_Codigo.SelectedItem == null)
        {
            if (MessageBox.Show(this, "No se puede ingresar un producto sin seleccionarlo.\n ¿Desea intentarlo de nuevo, o Salir?", "Error", MessageBoxButtons.RetryCancel, MessageBoxIcon.Exclamation) == DialogResult.Cancel)
            {
                DialogResult = DialogResult.Cancel;
                this.Close();
            }
        }
        else
        {
            var Principal = (PDQ.Cajero)this.ParentForm;
            Principal.CodigoInsertado = listBox_Codigo.SelectedItem.ToString();
            this.DialogResult = DialogResult.OK;
            this.Close();
        }
   }
   catch (Exception ex)
   {
        MessageBox.Show(ex.ToString());
        //LogException(ex);
   }
}
Austin Salonen
Try catch blocks aren't for debugging purposes. Instead in VS you select Debug->Exceptions and make sure you see everything that is thrown.
kubal5003
They'll be necessary in production anyway so you might as well use them in development.
Austin Salonen
@kubal5003 If it is faster and/or easier to just wrap in a try/catch to find the error, why not use it (and then if you really don't want a try/catch remove after you find the issue?) Seems like a waste to ignore a tool that can save time and effort
Gordon Tucker
Those that are in production are at carefully chosen places. Putting try-catch statements all over the code is the worst thing that you can do. It finally comes to a point that you can't debug anything, because of try-catch hell.
kubal5003
@Gordon Tucker"and then if you really don't want(..._ remove afrer you find the issue"One simple question: how many time have you done that? From my experience they always stay and then after let's say one month or half year you find that some @!@$@#%@#@ has left try-catch block and you've spent some hours trying to find out what was going on.
kubal5003
I think you missed my "event handler" clarification -- the reason I put them there is because it is the last line of defense in code I control (short of the UnhandledException event on AppDomain). Used elsewhere in code, they should be used when necessary and with specific intent.
Austin Salonen