How to catch CONSTRAINT Exception when adding duplicate unique id with VB

By : Tom

I have a problem that adding a new ROW with duplicate UNIQUE id throws CONSTRAINTException that I cannot always catch.. Randomly general exception halts my VB software, sometimes catching works. here is my code.

Private Sub BindingNavigatorAddNewItem_MouseUp()
      DataGridView1.CurrentRow.Cells(0).Value = InputBox("give new product id")
      Catch ex As Exception
        MessageBox.Show("error ") <-- never comes here!!
      End Try

end sub
Private Sub DataGridView1_DataError(..) Handles DataGridView1.DataError

        e.ThrowException = False <-- randomly comes here!!
        Dim v As DataGridView = CType(sender, DataGridView)
        v.Rows(e.RowIndex).Cells(e.ColumnIndex).ErrorText = "The value is wrong"
        MessageBox.Show("error 2") 

end sub
By : Tom


Two things, first how do you know that the database INSERT command is being executed within the context of the first procedure? I don't see anything there that would force the changes back to the database. Are you getting an unhandled exception with a stack dump that shows that it was called from that routine (and yet not handled)? Otherwise, I would say that there is a good chance that the INSERT is not being executed until sometime after that routine.

Secondly, it appears to me that the DataGridView1_DataError will squelch the error anyway. I beleive that the _DataError event will be invoked before it returns to the code that caused the INSERT to be executed and that "e.ThrowException = False" is spposed to prevent any repropagation of the exception.

You're right. In Windows, message pumps are "GUI things" although they are used for much more than that (hotkey notification, etc.).

A process can have a message pump per thread. Usually these are created when you create your first window. Console applications don't have message pumps. You could get around this by creating a Windows Forms window and making it invisible.

When you call Application.Run, Windows Forms will start your message pump. You can pass it the HWND of that window and it'll probably know what to do with it. If you want to catch messages sent back, you can override the forms WndProc. This will only catch messages sent to that window though...

By : Mendelt

Let me start with a little background on messages and message pumps.

In Windows, GUI applications work by handling messages. For example, when you move the mouse Windows sends a WM_MOUSEMOVE message to the window under the mouse.

Windows posts a message to the "message queue" of the thread that the window belongs to and someone has to route this message to the specific window. That someone is the message pump.

Every Windows UI framework has a message pump, and the simplest message pump looks like this (this code example is in C++; you can use interop to write it in .NET):

MSG msg;
while(GetMessage(&msg, hwnd, 0, 0))

Every GUI program must have a message pump, but a command-line program can start a message pump just by running the code above. Obviously, since you don't have open windows, you will not get any messages from the OS. To insert a message into the queue, use PostThreadMessage.

By : Nir

This video can help you solving your question :)
By: admin