I'm using Visual Basic .NET developing a windows form application and I want to toggle the enabled property of a Button based on if there is anything in a TextBox. I attempted to setup the DataBinding using the following:
ButtonBack.DataBindings.Add("Enabled", Me.TextBoxValue, "TextLength")
This successfully disables the Button, but whenever anything is typed in the TextBox, the Button never gets enabled. I would much rather do this via DataBindings if possible as opposed to setting the Enabled property manually in the TextChanged or Validating event of the TextBox.
I usually implement this kind of custom property binding by "subclassing" the control that requires the "new" property, as in your case, TextBox needs an HasLength Boolean property (or whatever name you want to give it).
Here's MyTextBox.vb:
Public Class MyTextBox
Inherits TextBox
Public Event HasLengthChanged As EventHandler
Private _HasLength As Boolean
Public Property HasLength() As Boolean
Get
Return _HasLength
End Get
Set(ByVal value As Boolean)
If value <> _HasLength Then
_HasLength = value
OnHasLengthChanged()
End If
End Set
End Property
Public Sub New()
_HasLength = False
End Sub
Protected Sub OnHasLengthChanged()
RaiseEvent HasLengthChanged(Me, New EventArgs())
End Sub
Protected Overrides Sub OnTextChanged(e As EventArgs)
MyBase.OnTextChanged(e)
HasLength = Not (String.IsNullOrEmpty(Text))
End Sub
End Class
And here's Form1.vb:
Public Class Form1
Protected Overrides Sub OnLoad(e As EventArgs)
MyBase.OnLoad(e)
ButtonBack.DataBindings.Add("Enabled", Me.MyTextBox1, "HasLength", True, DataSourceUpdateMode.OnPropertyChanged)
End Sub
End Class
Of course, you need a Form with a MyTextBox instance and a regular Button instance.
With this method, as soon as the user types something in the textbox, the button becomes enabled, and as soon as the textbox becomes empty, the button is disabled. Please note that I used the DataSourceUpdateMode.OnPropertyChanged so that the update is done as you type, and not only when the textbox loses focus.
EDIT: I thought I'd add a bit of background about the PropertyNameChanged pattern in .NET.
There are different ways to let observers know that a property has changed on an object, and most of the time we use the INotifyPropertyChanged interface, but for controls, the recommended method is still to use the PropertyNameChanged pattern, which is recognized by .NET, and thus the Binding object can do its job and know when the desired property has changed.
INotifyPropertyChanged is recommended for data objects that participate in binding.
By the way, the PropertyNameChanged works in both Windows Forms and WPF.
As reference MSDN:
https://learn.microsoft.com/en-us/dotnet/framework/winforms/how-to-apply-the-propertynamechanged-pattern
EDIT 2: I'm a C# programmer, and I've done my best to apply the residual knowledge that I have of VB.NET. Any error is really the result of my being too rusty in VB. Sorry for any inconvenience, but I can assure you that the code runs just fine here.
As #LarsTech stated in his comment, you need to use a property of the TextBox Class that raises changed notifications. The Text property is the appropriate one to use.
Your request to do this strictly via the binding is possible, but it will still involve using an event handler. As such, I don't see much value in this approach over handling the TextBoxValue.TextChanged event.
One way of doing this is to use the Binding.Format Event to convert the string of the Text Property to a boolean based on if it contains any characters.
Dim b As Binding = ButtonBack.DataBindings.Add("Enabled", Me.TextBoxValue, "Text", True, DataSourceUpdateMode.OnPropertyChanged)
AddHandler b.Format, Sub(s As Object, args As ConvertEventArgs) args.Value = Not String.IsNullOrEmpty(CStr(args.Value))
Because the binding is two way, if your code changes the ButtonBack.Enabled property, it will send the string representation of the property back to TextBoxValue and its text will read either "True" or "False". This would not be a desirable consequence. To rectify this possibility, the Binding.Parse Event will need to be handled.
AddHandler b.Parse, Sub(s As Object, args As ConvertEventArgs) args.Value = Me.TextBoxValue.Text
Related
Someone knows how to block the focus/select in a read-only textbox (ReadOnly = true), without using enabled = false?
Thanks!
Controls have a GotFocus Event. You can add an event handler for this event and give another control focus, for example by calling Select() on another control or by using SelectNextControl:
Private Sub MyTextBox_GotFocus(sender as Object, e as EventArgs) _
Handles MyTextBox.GotFocus
MyTextBox.Parent.SelectNextControl(MyTextBox, True, True, True, True)
End Sub
Alternately, you can create a custom control that inherits TextBox and set ControlStyles.Selectable to False.
Public Class NonSelectableTextBox Inherits TextBox
Public Sub New()
SetStyle(ControlStyles.Selectable, false)
End Sub
End Class
Setting ControlStyles.Selectable to false will make the TextBox mimic the behavior of other controls which have this bit set to False:
Label
Panel
GroupBox
PictureBox
ProgressBar
Splitter
LinkLabel (when there is no link present in the control)
I'm not sure I understand fully why you would want that. A read only text box allows selection to allow users to copy the text in there for other purposes. What I assume from your question is that you don't want the TextBox to accept input focus when a user is tabbing through controls, which I've seen to be a more common requirement.
You can achieve this via code:
TextBox1.TabStop = False
to ensure that tab doesn't direct focus to the readonly textbox. You can also achieve this in the designer using the same property as the screenshot shows.
I know I can add a DateTimePicker to my MenuStrip with the following lines
Dim dp = New ToolStripControlHost(New DateTimePicker)
MenuStrip1.Items.Add(dp)
But I can't figure out how to add a DateTimePicker to the MenuStrip at designtime. What's the trick behind it? I have been trying and searching for like an hour and I am about to give up even though I know there has to be a way!
TL;DR
How do I add a DateTimePicker to my MenuStrip at design-time?
Alternatively we can add it to a ToolStrip instead.
You are close to a solution in using the ToolStripControlHost, but you will need to derive from that class as shown in the linked-to example. The frustrating thing with that example is that it does not decorate the derived class with the System.Windows.Forms.Design.ToolStripItemDesignerAvailabilityAttribute to make it available on the design surface.
The following is a minimalist implementation to get a working example. You may need to override the automatic sizing to suit your needs/wants for the control. The implementation overrides the Text property to prevent designer from assigning invalid text to the underlying DateTimerPicker control.
<System.Windows.Forms.Design.ToolStripItemDesignerAvailability(
System.Windows.Forms.Design.ToolStripItemDesignerAvailability.ToolStrip _
Or System.Windows.Forms.Design.ToolStripItemDesignerAvailability.StatusStrip _
Or System.Windows.Forms.Design.ToolStripItemDesignerAvailability.MenuStrip)> _
Public Class TSDatePicker : Inherits ToolStripControlHost
Public Sub New()
MyBase.New(New System.Windows.Forms.DateTimePicker())
End Sub
Public ReadOnly Property ExposedControl() As DateTimePicker
Get
Return CType(Control, DateTimePicker)
End Get
End Property
<Browsable(False), EditorBrowsable(EditorBrowsableState.Advanced), DesignerSerializationVisibility(DesignerSerializationVisibility.Hidden)>
Public Overrides Property Text As String
Get
Return ExposedControl.Text
End Get
Set(value As String)
' verify valid date
Dim dt As DateTime
If DateTime.TryParse(value, dt) Then
ExposedControl.Text = value
End If
End Set
End Property
End Class
Was going to add as a comment but I trust it justifies an answer.
The only way I have succeeded in this is to add one at design time (to the form) and set Visible to False and use the menu item to set Visible to True (may also need to set the position and/or bring it to the front).
You do need to manually handle setting Visible to False again.
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 made a class that handles the display of a set of controls. These controls are created at runtime. Because of that, I have to add them to an event handler at runtime as well. I made a function that allows me to specify the event handler to be used for some of the controls. The code looks like this:
Here's the main form
Dim displayObj as PackageDisplay = new PackageDisplay(AddressOf CheckBox_CheckedChanged)
The constructor does this
Public Sub New(ByRef eventHandler as Action(Of System.Object, EventArgs)
AddHandler chkExample.CheckedChanged, eventHandler
End Sub
However, I get the following error:
Value of type 'System.Action(Of Object, System.EventArgs)' cannot be converted to 'System.EventHandler'
It surely must be possible to pass an event handler and assign it, but I just don't know how. I've tried several different variations of this, but I can't figure out how to make this work. Any ideas?
You don't need to make one, use the stock System.EventHandler.
I have a simple LoginForm.
Here is how the code-behind looks like:
Private Sub btnLogin_Click(sender As Object, e As RoutedEventArgs) _
Handles btnLogin.Click
If Me.loginForm.ValidateItem() Then
'Do the actual login - (calling VM command)
DirectCast(Me.DataContext, LoginViewModel).LoginCommand.Execute()
End If
End Sub
Now I created a LoginViewModel that exposes a LoginCommand. I would like to keep the code-behind clean, and in the other hand, leave the ViewModel UI independent.
What should be the cleanest way to do this?
I am looking for an application level solution so I can make all the controls UpdateSourceTrigger=PropertyChanged or another workaround whatsoever to requery the CanExecute command when attempting click.
Update after Jon's answer:
So where should I call this method from, should it be the Login?
Private m_LoginCommand As ICommand
Public ReadOnly Property LoginCommand() As ICommand
Get
If m_LoginCommand Is Nothing Then m_LoginCommand =
New DelegateCommand(AddressOf Login, AddressOf CanLogin)
Return m_LoginCommand
End Get
End Property
Private Function CanLogin() As Boolean
Return Not IsLoggingIn
End Function
Private Sub Login()
DirectCast(LoginCommand, DelegateCommand).RaiseCanExecuteChanged()
If Not CanLogin() Then Exit Sub
'Do login
End Sub
It isn't completely clear what your goal is, so I hope I got this right.
Assuming you are using Prism, then whenever LoginCommand's can-execute status is changed (which is done from your ViewModel), the VM should immediately call RaiseCanExecuteChanged on it. This will notify all controls that bind to this command that they need to requery the CanExecute status.
If you are not using Prism, your command class should have some similar mechanism.
In any case, you don't need to do anything from the View.