I want to fire an event in another class.
And my problem is I don't know how to make it.
I'm trying to use Inherits statement to my Form and add my class name to it, and it works as I hope:
Public Class Frm_Main_Copy
Inherits ToolStripMenuApp
'I have a ToolStripMenu that has declared before on my class and it sounds like this:
'Public Shared WithEvents Cat000x86_64App As ToolStripMenuItem
...
Private Sub IsClicked(ByVal sender As Object, ByVal e As EventArgs) Handles Cat000x86_64App.Click
End Sub
End Class
but the designer form messed up(returns a fatal error) and I should delete the Inherits statement, and the others.
Tried to act as form designer script(Trying to put this code to my class):
Friend WithEvents BlahBlah As RadioButton 'For example
It didn't worked,
Declaring a variable for my class and It didn't worked too
Searched on the Internet and it seems likely more complicated than I thought...
Anyone can help? Any help is appreciated.
A form is not a form unless it inherits, either directly or indirectly, the Form class. You cannot inherit any type that is not itself a form and expect your type to be a form. With that code, if ToolStripMenuApp is not a form then Frm_Main_Copy is not a form either, hence no form designer.
If what you're actually saying is that you have an instance of that ToolStripMenuApp that contains a TooStripMenuItem whose Click event you want to handle in Frm_Main_Copy then the first step is to not declare Cat000x86_64App as Shared. Frm_Main_Copy needs to declare a method capable of handling that event:
Private Sub IsClicked(ByVal sender As Object, ByVal e As EventArgs)
'...
End Sub
Note that there is no Handles clause because there's no WithEvents variable in that class whose event you are handling.
Next, Frm_Main_Copy must have access to the appropriate instance of ToolStripMenuApp. It's impossible for us to say how best to do that based on the information provided but it might be as simple as this:
Dim tsma As New ToolStripMenuApp
You then register your method as a handler for the appropriate event:
AddHandler tsma.Cat000x86_64App.Click, AddressOf IsClicked
If you use AddHandler, make sure to use RemoveHandler when you're done with either object. I suggest that you do some reading based on this information.
Related
I'm using VB .NET to create a planning, and I got a little problem with events.
In the main form, I put a panel in which I add programatically rows and boxes in those rows. I have inside the form a TextBox and the panel that contains all the boxes. I want to change a the text of the TextBox when I click on a box, so I use the AddHandler statement but it doesn't work. I tried to debug it and I realised that it actually calls the sub and inside it, I can see the changes it makes (TextBox.Text becomes what I want), but when it exits the sub, it is like nothing has changed.
I don't know if I was clear enough.
Thanks
Here is a simplified code (I removed all the graphics functions to resize the controls...)
Public Class frmPrinc
Public actEditing As Object
Private Class boxAct
Inherits Label
Public act As Integer
Public Sub New(ByVal a As Integer)
act = a
AddHandler Me.Click, AddressOf clickBox
End Sub
Private Sub clickBox(sender As Object, e As EventArgs)
Dim boxact As boxAct = DirectCast(sender, boxAct)
frmPrinc.actEditing = boxact
boxact.Text = "Clicked"
End Sub
End Class
Private Sub showPlanning()
pan_plan.Controls.Clear()
Dim plan As New Control ' Control that will be used as a row
For i As Integer = 0 To 10
plan.Controls.Add(New boxAct(i))
Next
Panel1.Controls.Add(plan)
End Sub
End Class
When I run that, the text of the box changes but actEditing is still Nothing...
Instead of boxAct trying to directly update frmPrinc of the current "box" being clicked, it should instead raise a Custom Event that frmPrinc subscribes to. frmPrinc can use that information as it then sees fit. Below I've added the custom event and raise it in class boxAct. The form subscribes to that event using AddHandler when each instance of boxAct is created. All together, this looks something like:
Public Class frmPrinc
Public actEditing As boxAct
Public Class boxAct
Inherits Label
Public act As Integer
Public Event BoxClicked(ByVal box As boxAct)
Public Sub New(ByVal a As Integer)
act = a
End Sub
Private Sub boxAct_Click(sender As Object, e As EventArgs) Handles Me.Click
Me.Text = "Clicked"
RaiseEvent BoxClicked(Me)
End Sub
End Class
Private Sub showPlanning()
pan_plan.Controls.Clear()
Dim plan As New Control ' Control that will be used as a row
For i As Integer = 0 To 10
Dim box As New boxAct(i)
AddHandler box.BoxClicked, AddressOf box_BoxClicked
plan.Controls.Add(box)
Next
Panel1.Controls.Add(plan)
End Sub
Private Sub box_BoxClicked(box As boxAct)
actEditing = box
Debug.Print("Box Clicked: " & actEditing.act)
End Sub
End Class
From the comments:
Thanks man, it worked! I'd like to know though why I need to make such
a structure to raise a simple event that modifies the main form...
Just to not do the same mistake again – Algor Frile
This a design decision everyone must make: "Loosely Coupled" vs. "Tightly Coupled". The approach I gave above falls into the Loosely Coupled category. The main benefit to a loosely coupled solution is re-usability. In your specific case, we have Class boxAct being reused multiple times, albeit all within the same form. But what if that wasn't the case? What if you wanted to use boxAct on multiple forms (or even have multiple "groups" of them)? With your original approach, you had this line:
frmPrinc.actEditing = boxact
which means that if wanted to use Class boxAct with a different form you'd have to make a copy of Class boxAct, give it a new name, and then manually change that one line to reference the new form:
Public Class boxAct2
Private Sub clickBox(sender As Object, e As EventArgs)
Dim boxact As boxAct = DirectCast(sender, boxAct)
frmSomeOtherForm.actEditing = boxact
boxact.Text = "Clicked"
End Sub
End Class
This shows the disadvantage of the Tightly Coupled approach, which uses references to specifics types (the Form in this case) to communicate. The Tightly coupled approach might be initially easier to implement when you're coding fast and furious, but then it suffers from re-usability down the line. There are scenarios in which a tightly coupled solution make sense, but only you can make that decision; those scenarios usually involve some kind of "sub-control" that will only ever get used within some kind of custom container/control and will never be used on its own somewhere else.
Conversely, with the loosely coupled approach, if we wanted to re-use Class boxAct in a different form, then no changes to it would be required at all (though at that point you'd probably not want it declared within your original Form!). In the new form you'd simply add a handler for the BoxClicked() event and then do what you need to do. Each form would receive the events for its respective instances of boxAct.
Final thoughts...your original approach could actually work, but most likely was failing at this line (same as above):
frmPrinc.actEditing = boxact
Here you were referencing to frmPrinc using what is known as the Default Instance of that form. This would have worked if frmPrinc was the "Startup Object" for your application. I'm guessing it wasn't, however, and you were creating an instance of frmPrinc from somewhere else. To make the original approach work you would have had to pass a reference to your ACTUAL instance of frmPrinc into Class boxAct (usually via the Constructor in tightly coupled solutions).
I have made a title bar (custom user control) that contains five controls. They are all labels but each one do different "job".
For example, one of them is an exit form button. If I put a click event into my custom user control's code, for example...
Private Sub ExitButton_Click(sender As Object, e As EventArgs) Handles ExitButton.Click
Close()
End Sub
I get this error...
BC30451 'Close' is not declared. It may be inaccessible due to its protection level.
On the other hand I can't put it into my project's code cause it can't find ExitButton as "isolated" control and do close().
Any suggestions? I also want to do the same thing with minimize, maximize etc.
Let me guess; your button is in the user control. You try to call Close() on the UserControl class, which obviously is not a window and does not have it.
There are three solutions:
Use the ParentForm property and call Close() on it (e.g. ParentForm.Close()). Easy but not too flexible; if you want to do other things than those which are implemented in the Form base class (like Close()), e.g. specific to the main form, you would have to cast it first and check if it's really the form you thought of. Also, all those things would need to be exposed with Public or Internal, don't expose what you don't have to expose.
You pass the Form to the UserControl. Horrible because passing stuff around just ends up in spaghetti code.
Better, raise an event by the UserControl which you handle in the form the UserControl is on. That's probably the most flexible approach.
Here's a small code example solving this with an event:
Open the code of the UserControl and add an event signature and raise that event when you click the button:
Public Class MyUserControl
Public Event ButtonClicked(sender As Object, e As EventArgs)
Private Sub MyButton_Click(sender As Object, e As EventArgs) Handles MyButton.Click
RaiseEvent ButtonClicked(sender, e)
End Sub
End Class
Then, in your Form, attach to the ButtonClicked event of the UserControl:
Public Class MyForm
Private Sub MyUserControl1_ButtonClicked(sender As Object, e As EventArgs) Handles MyUserControl1.ButtonClicked
Close()
End Sub
End Class
If you re-use the event for multiple buttons, you can check which button it is through the sender passed to the event. (Of course this can be optimized by just passing a casted Button instance as the event parameter, this is just a simple example).
Where did you get "close" from? You exit an application with application.exit()
If you want to close Application you can use:
Application.Exit()
If you want to close Form:
Me.Close()
To close the form you use me.
me.close
I have created a Form with Objects like Progressbar and Button.
I have also created Public library code outside my Form
I want to modify the Progressbar Control or the Button's Text from a Sub that is written in a library (I try to pass my Form as a parameter):
Public Shared Sub ModifyItems(ByRef _WhichForm As Form)
_WhichForm.MyProgressBar1.visible = True
End sub
Unfortunately, the code Is not recognizing the Progressbar name MyProgressBar1
Is there a way to modify the Progressbar Control on the Form directly in a Sub or Function that is written in a class library, not directly in the Form Code ?
This type of approach would generally fall under the umbrella of "bad practice". Having objects modifying each others members directly introduces tight coupling that makes for difficult code to extend, debug, and maintain.
Rather than trying to modify something from within the library, better to think in terms of notifying that something within the library has changed. You could, for example, raise an event within the library. Form1 could then listen for that event and make any changes to its components that are appropriate. This way Form1 is solely responsible for modifying its components and the library is solely responsible for announcing changes to its internal state.
To give a good example - if, say, you were to change your Form's progress bar component (maybe you find a better one out there) you suddenly introduce a breaking change into your library.
To use an event you might do something like :
Public Class MyLibrary
Event OnSomethingHappened()
Private Sub SomethingHappened()
RaiseEvent OnSomethingHappened()
End Sub
End Class
And then in your form :
Public Class Form1
Private WithEvents _myLibrary as New MyLibrary
Private Sub LibraryDidSomething() Handles _myLibrary.OnSomethingHappened
MyProgressBar1.Visible = True
End Sub
End Class
This nicely decouples any dependence on Form1 - the library exists as a self-contained entity and doesn't care who listens to its events.
If you want to do this with a shared class you can also use shared events - these must be connected programmatically as :
Public Class MyLibrary
Shared Event OnSomething()
Public Shared Sub DoSomething()
RaiseEvent OnSomething()
End Sub
End Class
in the form :
Public Class Form1
Private Sub Form1_Load(sender As System.Object, e As System.EventArgs) _
Handles MyBase.Load
AddHandler MyLibrary.OnSomethingHappened, AddressOf LibDidSomething
End Sub
Private Sub Form1_FormClosed(sender As System.Object, e As _
System.Windows.Forms.FormClosedEventArgs) Handles MyBase.FormClosed
RemoveHandler MyLibrary.OnSomethingHappened, AddressOf LibDidSomething
End Sub
Private Sub LibDidSomething()
MyProgressBar1.Visible = True
End Sub
End Class
When programmatically adding events you must take care to remove them before disposing of the objects that have subscribed to them. In this case I have added the handler when the form loads and have removed it when the form closes. If you fail to remove an added handler then the form would not be garbage collected and this would cause a memory leak.
See here for more reading : Raising Events and Responding to Events (MSDN)
I have a Button in UserControl1.
I am using UserControl1 in Form1.
I want to handle Button's Click event in Form1.
I tried to do same via:
AddHandler userControl1.Button1.Click, AddressOf Button1_Click
And:
Public Sub Button1_Click(ByVal sender As Object, ByVal args As EventArgs) Handles userControl1.Button1.Click
End Sub
but getting error.
Create your event on the UserControl:
Public Class UserControl1
Public Event UC_Button1Click()
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
RaiseEvent UC_Button1Click()
End Sub
End Class
And then use the new event:
AddHandler userControl1.UC_Button1Click, AddressOf Button1_Click
Or you can simply define it like this on the UserControl and access to it from outside (not recommended):
Public WithEvents Button1 As System.Windows.Forms.Button
And then:
AddHandler uc.Button1.Click, AddressOf Button1_Click
I found this very confusing until I placed the "AddHandler" in the main program (not the UserControl).
So for clarification, the steps to ensure that you can "sense" in the main program an event which has occurred in a user control is:
Make sure any object in your user control for which you wish to alter properties (such as PictureBox.Image or TextBox.Text) has its modifier property set to "Public".
This is the only way you can allow other programs to alter properties.
For events which your want recognised (e.g. "Click","DblClick" etc.) place at the top of your User Control code one declaration line for a Public Event. As an example,
Public Event UC_MySub(.....parameters.....)
"UC_" is a prefix I use to help highlight that it is defined in a "UserControl".
The rest of the name ("MySub") can be anything and does not need to relate to the Click Event in any way. You could even call it "CreamedCheese" if you want!
Include any parameters you like the the definition of the public event, again they can be any type of name. These will be passed to the main program when you click on the User Control's object.
Now, Going to the event which runs when you "click" on a GroupBox (in this case), you kick off that public event as shown here:
Private Sub GroupBox_Click(sender As Object, e As EventArgs) Handles GroupBox1.Click
RaiseEvent UC_MySub(....Paramaters.....)
End Sub
You have to ensure the parameters passed in this call to the public event are the same in number (and type) as each of the parameters defined in the Public Event declaration itself.
NOW, you rebuild your User Object, then go to your main program.
In the "Load" routine of your main Form, add the following line FOR EACH OBJECT of the user defined object you are using.
For example, in my program I have 4 instances of my UDO (User Defined Object).
So I have added (assuming my UDO is named "MyUDO"):
AddHandler MyUDO1.UC_MySub, AddressOf SwapHands 'This is my sub accepting the values from the public event
AddHandler MyUDO2.UC_MySub, AddressOf SwapHands
AddHandler MyUDO3.UC_MySub, AddressOf SwapHands
AddHandler MyUDO4.UC_MySub, AddressOf SwapHands
The "SwapHands" routine is defined in my main program and accepts the parameters stored in the UC Public event. The "AddressOf" points your resident subroutine.
The only thing to ensure across all these definitions is that you have the same number of parameters (if you have any) in each case, in the same order, and are of the same type).
(Each parameter can be a different type but must "line up" in types declared in each
definition). (e.g. 1 Boolean, 1 String, another string). In the definitions and calls, there have to be (in this case) 3 parameters of "Boolean, String, String" - in that order.
Now when you run the program and click on the GroupBox (or whatever you have used) in your UDO (User defined object) (on any one of the four objects in this case), you will kick off the routine stored in your main program.
Hard to explain, but after taking HOURS to fathom how this works, I thought I would leave my comments in case others are experiencing the same confusion.
I try tu use this msdn snipped to execute some code right after my form loads:
Private Sub Form1_Shown(sender as Object, e as EventArgs) _
Handles Form1.Shown
Some Code
End Sub
But it seems that I am missing something. I get an errormessage that translated sounds like this:
The Handle requiere an WithEvents-Variable, which is defined in the contained type or its basis class... My Form is named Form1 so that should be ok. the error is marked in the second line of the code. Any ideas?
Instead of:
Handles Form1.Shown
do this:
Handles Me.Shown
Usually that is the sort of error you would get if you create the form in code and not in the designer. The designer will automatically declare the generated form as WithEvents. If you create the Form in code instead you have to declare it as WithEvents.
For example:
Public Form1 as frmMain
Would generate that error unless you add the handler yourself.
AddHandler Form1.Shown, AddressOf Form1_Shown
If you do this instead:
Public WithEvents Form1 as frmMain
wouldn't generate the error.
WithEvents is necessary on any object created if you want to use the handles clause in that way.