[RESOLVED] Auto saving of changed data.

I have a Cancel button on a form. This event is designed so that there is a query to ask the user if they want to save any changes made to the content of the record (see the lower code block). I have eliminated this query and changed the event to just go ahead and save any changed in the record content. This is done using the first code block below, as opposed to the original process.

It works fine, but I have a combobox and I want to be able to include any changes made to the text property of that control. cboOwner.modified won't work, as I suspected. How can I check cboOwner for a change in cboOwner.Text?

I am sure that there are probably numerous ways to achieve this, and I would be happy to consider them, but this was the only thing that came to mind that worked for me with the textbox controls.

Code:

---

       
        If txtTask.Modified Or txtStart.Modified Or txtEnd.Modified Or txtComplete.Modified Or txtNotes.Modified Then
            btnSave.PerformClick()
        Else
            Me.Close()
            taskList.btnRefresh.PerformClick()
            taskList.Show()
        End If

---

Original method

Code:

---

        If SaveTask <> True Then
            If MessageBox.Show(SaveMessage, "Cancel Task Changes", MessageBoxButtons.YesNo, MessageBoxIcon.Warning) = MsgBoxResult.Yes Then
                btnSave.PerformClick()
                SaveTask = True
            End If
        End If
        Me.Close()
        taskList.btnRefresh.PerformClick()
        taskList.Show()

---

You could just store the SelectedIndex of the ComboBox when you load the data and then compare the current value to that.

BTW, you should be using OrElse rather than Or. ALWAYS use AndAlso and OrElse in preference to And and Or unless you specifically don't want short-circuiting.

Thanks. Just goes to prove that you can get caught up in doing something fancy when the easy way is sitting right there staring at you.

Quote:

---

you should be using OrElse rather than Or. ALWAYS use AndAlso and OrElse in preference to And and Or

---

Just a habit of mine. I will try to correct that tendency. Although now that I think about, why is that so? It is not obvious to me.

And and Or check all conditions... AndAlso and OrElse will check conditions up to the first one that returns a value to cause the entire expression to fail...
In hte case of AndAlso it will keep checking as long as each part of the expression returns true. As soon as it finds a the first false condition, it short circuits and exits since there's no reason to check furhter.
OrElse keeps checking as long as values are false ... when the first true condition is found, it exits the checks and drops into the control block.

It's the difference between this:

Code:

---

If someValue is Null Or someValue.length =0 Then

---

Failing because of a null pointer exception... you can't get hte length of a null object...

and this:

Code:

---

If someValue is null OrElse someValue.length = 0 Then

---

Which will work because it sees that someValue is in fact null, so that's true so there's no reason to check someValue.length... the condition is already true.

-tg

Quote:

---

Originally Posted by gwboolean

why is that so? It is not obvious to me.

---

tg explained it pretty well but, to add my 2 cents, short-circuiting means that only as many conditions are checked as are necessary to get a final result. If you have 100 conditions separated by AND operators, if the first one is False then the entire expression will always be False, no matter the values of the remaining conditions. AndAlso will short-circuit and not even check the other conditions whereas And would check every one regardless. Usually it will not matter much either way. If the conditions are simple comparisons then they will be very fast so, while AndAlso will be faster, the difference will be negligible. When it becomes important is when one or more of your conditions have side-effects. You should only use And/Or if you specifically want those side-effects to occur every time. That said, it's bad practice to have your conditions in such an expression have side-effects anyway, because it is not obvious that it's the case to anyone reading the code without actually digging into that condition.

With regards to tg's example, that was a very important example of where you really must use short-circuiting up until recently, but the null-propagation operator has made that sort of thing moot. Where you might previously have done this:

vb.net Code:

If someObject IsNot Nothing AndAlso someObject.SomeProperty Then

now you can do this:

vb.net Code:

If someObject?.SomeProperty Then