[RESOLVED] [2005] Getting data back from a user control to a parent control
Hello,
I have a user control. See the image below. The tab control is not part of the user control. but everything inside is.
When a user wants to delete a task the taskID is taken from the tab name and passed to the user control in a public property. So I know what task I want to delete.
Code:
'Code in the user control
Public Property TaskID() As Integer
Get
Return _taskID
End Get
Set(ByVal value As Integer)
_taskID = value
End Set
End Property
'
Code:
In the parent form I get the TaskID from the tab name and pass it to the public property
Private Sub TabControl1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles TabControl1.Click
Try
Dim taskID As Integer = 0
taskID = Integer.Parse(Me.TabControl1.SelectedTab.Name)
newTask.TaskID = taskID
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub
But the problem is when I delete I want to be sure that the deletion was successful and pass this back to the parent control. And that is something I can't see to do.
For example: if there was a problem with the delete then I don't want to delete the tab but inform the user there was a problem.
Code:
'code in the user control for deleting the task, but if not successful, how do i send this back to the parent control?
Private Sub btnDelete_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles btnDelete.Click
Try
Dim rowsAffected As Integer = 0
rowsAffected = Me.TA_IncidentTask1.DeleteTask(_taskID)
If (rowsAffected = 0) Then
'Not successful so how do i inform the user
End If
Catch ex As Exception
MessageBox.Show(ex.Message)
End Try
End Sub
I am ok at passing information to the user control by using public properties as you have seen in the code above. But i need to know if the delete was successful or not.
Can anyone help and advice me on this. code examples would be most grateful.
Re: [2005] Getting data back from a user control to a parent control
Your UserControl can raise an event that the TabPage or TabControl can handle. You can pass information in the EventArgs of that event to indicate whether the delete operation was successful or not.
Re: [2005] Getting data back from a user control to a parent control
Hello,
I have put this could in my form1 that I hope will catch the event.
vb Code:
Public Sub DeleteAttempted(ByVal sender As Object, ByVal e As TaskControl.DeleteAttemptedEventArgs) Handles newTask.DeleteAttempted
MessageBox.Show("Delete attempted - success at last")
End Sub
have not dragged my user control on the form. As I create one at run-time. For example
I add a reference to it.
The solution the user control was created in, is called TaskControl.
So in my new project i right click add reference, browse and select TaskControl.
Then in my form1 i write imports TaskControl.
In the code designer of the form1 i write:
Friend WithEvents newTask As TaskControl.QuickTasks
For some reason it does not fire in form1, so will never know if a delete happened or not.
Any more guidance would be truly grateful, i think i am out of all ideas.
Re: [2005] Getting data back from a user control to a parent control
How do you normally create event handlers? It's no different in this case. Either select the UserControl in the designer, open the Properties, click the Events button then double-click the desired event, or else open the code window, select the variable from the drop-down list at the top left and the event from the top right. An event is an event, whether it was declared by the Framework creators at Microsoft, some third-party vendor or yourself.
Re: [2005] Getting data back from a user control to a parent control
So, you declare a variable like this:
vb Code:
Friend WithEvents newTask As TaskControl.QuickTasks
and you have an event handler like this:
vb Code:
Public Sub DeleteAttempted(ByVal sender As Object, ByVal e As TaskControl.DeleteAttemptedEventArgs) Handles newTask.DeleteAttempted
MessageBox.Show("Delete attempted - success at last")
End Sub
That means that that method is handling the DeleteAttempted event for the object referred to by the 'newTask' variable. When you create your QuckTasks object at run time, do you assign it to that variable?
Re: [2005] Getting data back from a user control to a parent control
Hello Jmc,
I always first try the code way before i try the designer way. It gives me greater understanding when learning this.
I created a new project and dragged the user control over and added the event by the properties window. It generated the code and worked fine.
vb Code:
Private Sub QuickTasks1_DeleteAttempted(ByVal sender As System.Object, ByVal e As TaskControl.DeleteAttemptedEventArgs) Handles QuickTasks1.DeleteAttempted
MessageBox.Show("Delete attempted - success at last: " & e.Deleted)
End Sub
Now I do the same at run-time.
vb Code:
Imports TaskControl
Public Class Form1
Friend WithEvents newTask As TaskControl.QuickTasks
Public Sub DeleteAttempted(ByVal sender As Object, ByVal e As TaskControl.DeleteAttemptedEventArgs) Handles newTask.DeleteAttempted
MessageBox.Show("Delete attempted - success at last: " & e.Deleted)
End Sub
Private Sub Form1_Load(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles MyBase.Load
newTask = New TaskControl.QuickTasks
Me.Controls.Add(newTask)
End Sub
End Class
This also worked as well. So i have learnt how to do this at run-time and design time.
However, none of the above worked in my current project, i had to create a new one to get this to work. Any possibly reason for this?
I know it might be too much to ask, but could you possibly explain in easy terms what the code you gave me in post #4
many thanks for your help,
Last edited by steve_rm; Apr 15th, 2007 at 08:39 PM.
Re: [2005] Getting data back from a user control to a parent control
Originally Posted by steve_rm
could you possibly explain in easy terms what the code you gave me in post #4
The first code block is a class that inherits EventArgs. The EventArgs class exists specifically to pass data to event handlers. Any event that doesn't require any data receives an EventArgs object, which is the base class. If you are declaring an event that DOES require data then you need to inherit the EventArgs class and add properties for that data. In our case our event handlers need to know whether the delete operation was successful or not, so we added a Boolean property that provides that information.
The second code snippet is the declaration for the event itself and the method that raises it. The convention is to ALWAYS have the event raised by one and only one method, which has the same name as the event prefixed with "On". The method is also declared Protected Overridable so that it cannot be invoked form outside the class but any derived types can modify the behaviour. The event declaration means that DeleteAttempted is an event whose handlers will receive a DeleteAttemptedEventArgs object. This:
vb Code:
#
Public Event DeleteAttempted As EventHandler(Of DeleteAttemptedEventArgs)
is equivalent to this:
vb Code:
#
Public Event DeleteAttempted(ByVal sender As Object, ByVal e As DeleteAttemptedEventArgs)
The third code snippet shows how you raise the event. Like I said, you should raise the event from one and only one method. That way if you ever change the implementation, or a derived class does, everything will remain consistent. That means that whenever you want to raise the DeleteAttempted event you call the OnDeleteAttempted method. That method has one argument that contains the DeleteAtemptedEventArgs object that will be passed to any methods that handle the event. You need to create that object and set its Deleted property with a value that indicates whether the operation succeeded or not.
The final code snippet is what you'd put inside an event handler for that event. The object create the DeleteAttemptedEventArgs object to indicate whether the deletion was successful. It then raises that event and passes that object. Every event handler then receives that object. The whole point of the event is to know whether the deletion was successful or not, so you need to check the appropriate property to find out.