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.
Related
I have declared a form as
Private _fUpdate As frmUpdate
There are all kinds of solutions to check if a form is open and visible.
However, if a form is Minimized and not shown in the taskbar, it doesn't show up in Application.OpenForms.
Also Form.IsHandleCreated returns false with the above window state.
If Not uForm Is Nothing returns True even if the form has not yet been instanciated, so it isn't usuable as well.
Is there another way to check whether a form is loaded then a variable storing the window existance and hidden/shown state?
What I usually do if I need to get the instance of a form from somewhere else within my application, is create a Shared property in your form called Instance or something similar and set it in the form's Load event.
With this instance property, you can call it from anywhere else in your application, and use the WindowState property of your form to check its state.
Example of the form:
Public Class frmUpdate
Public Shared Property Instance As frmUpdate
Private Sub OnLoad(sender As Object, e As EventArgs) Handles MyBase.Load
Instance = Me
End Sub
End Class
Example usage in some other method:
Private Sub DoSomething()
If (frmUpdate.Instance.WindowState = FormWindowState.Minimized)
'Do something
End If
End Sub
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
To start with I have a fairly unique situation in that I am dealing with large amounts of data - multiple series of about 500,000 points each. The typical plot time is about 1s which is perfectly adequate.
The chart is created 'WithEvents' in code and the plot time doesn't change.
However, when I add the sub with the handler for the click event ..
Private Sub Chart_Main_Click(ByVal sender As Object, _
ByVal e As MouseEventArgs) Handles Chart_Main.Click
Dim y As Integer = Chart_Main.ChartAreas(0).AxisX.PixelPositionToValue(e.X)
'MsgBox(y)
End Sub
the plot time blows out to 3min. Even having no code in the sub, the result is the same. There is no reference to the click event in any of the code so I am at a loss as to why this is occurring. I suspect it has something to do with the number of points being added but not knowing the cause is frustrating.
Is anyone able to explain what is going on?
Ok, i don't know if the explanation in the comments was sufficient, so here some example code...
Also i wanted to try this myself!
Essencially, what you do is take control on when you want Windows to check the events.
For that, i suggested two wrappers on AddHandler and RemoveHandler that can safely be called from worker threads.
So, what you have to do, is:
Initialize the Handler in the constructor
Call RemoveClickHandler on your control, each time you want it to be left alone by the EventHandler
But don't forget to reinitialize the handler afterwards via AddClickHandler
Also, your handler method should not have the 'Handles' keyword anymore...
Public Class MainForm
Public Sub New()
' This call is required by the designer.
InitializeComponent()
m_pPictureClickHandler = New MouseEventHandler(AddressOf hndPictureClick)
AddClickHandler(pbxFirst, m_pPictureClickHandler)
End Sub
' Have a persistent local instance of the delegate (for convinience)
Private m_pPictureClickHandler As MouseEventHandler
Public Sub AddClickHandler(obj As Control, target As [Delegate])
If Me.InvokeRequired Then
Me.Invoke(New Action(Of Control, [Delegate])(AddressOf AddClickHandler), obj, target)
Else
AddHandler obj.MouseClick, target
End If
End Sub
Public Sub RemoveClickHandler(obj As Control, target As [Delegate])
If Me.InvokeRequired Then
Me.Invoke(New Action(Of Control, [Delegate])(AddressOf RemoveClickHandler), obj, target)
Else
RemoveHandler obj.MouseClick, target
End If
End Sub
' Here your Plot is done
Public Sub LockedPlot()
RemoveClickHandler(pbxFirst, m_pPictureClickHandler)
' do something on your handler free control ...
AddClickHandler(pbxFirst, m_pPictureClickHandler)
End Sub
' This is your handler (note without a 'Handles' keyword)
Private Sub hndPictureClick(sender As Object, e As MouseEventArgs)
' do something with the click
MessageBox.Show(String.Format("Yeah! You clicked at: {0}x{1}", e.X.ToString(), e.Y.ToString()))
End Sub
End Class
I suppose an even better design would be to create a child class of your chart that has an LPC style method called, say 'SafePlot', with folowing features:
It accepts a pointer (delegate) to a procedure
It will remove all the event handler before invoking the procedure
Finally it would reinitialize the handlers on it's own after the job is done.
It may require a collection to all handler refering to it's events.
-> For that reason i'd let the class manage the handlers entiraly...
Alternativly you could put the 'SafePlot' idea in your main class. then you could manage the event handler there... but that is disputable
Well i can think of a few other ways to do this, but i'm cutting the brainstorming now!
If interested in one of these design solutions, give me a poke.
Running into an odd issue with tasks and delegates. Code in question is running under dotNET 4.5.1, VS2013. On the form's code I have a sub that updates a grid, it checks to see if an invoke is required, and if it is it calls a delegate. When a task runs that's called in the same module, it works as expected, no problems. Threaded or not, the grid updates properly.
However, if the same thing is called from another module, the delegate never gets called and the visual component doesn't get updated. Just a watered down bit of pseudocode to clarify..
In the form's module:
Private Delegate Sub DoWhateverDelegate(ByVal _____)
Public Sub DoWhatever(ByVal _____)
If MyComponent.InvokeReqired
Dim Delegated As New DoWhateverDelegate(AddressOf DoWhatever)
Debug.Print("The delegate fired")
Invoke(Delegated, _____)
Else
' .. carry on as usual ..
End If
End Sub
Elsewhere....
Task.Run(Sub()
' .. various things I'd rather not block the UI thread with ..
DoWhatever()
End Sub)
Works fine. I can do Task.Run__ that calls DoWhatever and it's all happy and good. However if I create a task in another module and call DoWhatever, it doesn't fire the delegate and that visual component doesn't update. The code is identical, in the same module it works, in another module it does not.
I'm probably missing something blatantly obvious.. anyone care to point out my mistake? Thanks.
Edit -- just to clarify, that other module is just code, there's only one form in the entire solution. It's created at program startup automatically, there is no other form creation going on.
Should be a thread-specific issue. Check this:
Public Class Form1
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
foo.DoSomething()
End Sub
End Class
The class with the delegate:
Public Class foo
Public Shared Sub DoSomething()
Task.Run(Sub() UpdateText())
End Sub
Public Delegate Sub UpdateTextDelegate()
Public Shared Sub UpdateText()
Dim f = Form1
'Dim f As Form1 = Application.OpenForms("Form1")
If f.InvokeRequired Then
Dim d As UpdateTextDelegate = AddressOf UpdateText
f.Invoke(d)
Else
f.TextBox1.Text = "Hi"
End If
End Sub
End Class
Run the code and the textbox will not be updated. Use the second f=.... (that one that take a reference from OpenForms) and it will be updated.
If you just try to access the default instance and you are outside the UI-thread, a new instance of the form will be created. That means, the content IS updated, but because that form is not shown, you will not see it.
NOTE I do NOT advise to solve your problem, by using OpenForms. I'd advise to correctly instantiate forms!
Add a new module/class to your code:
Module Startup
Public MyForm1 As Form1
Public Sub main()
MyForm1 = New Form1
Application.Run(MyForm1)
End Sub
End Module
Go to project properties -> application. Disable application framework and choose Sub Main as your start object. In the app, access your form via MyForm1 - or whatever you want to name it. Problem should be gone then.
I am building a custom control and what i would like to do is have an event lets call this event OnMenuShow. Now what i would like to be able to do is handle this event inside my control to show one menu but allow the user implementing my custom control to handle the event in inside the parent form to show a different menu if they wish. so the users code would look something like this.
Public Sub Control_OnMenuShow(sender as Object, e as CustomEventArgs) handles Control.OnMenyShow
'DO some work
e.handled = true
end Sub
I'm just not sure on how to prevent the event from firing twice once for the code inside the control the other in the event. if someone could point me in the right direction that would be very helpful
-Nathan
In your control:
Public Event MenuShow As EventHandler
Public Overridable Sub OnMenuShow()
RaiseEvent MenuShow(New EventArgs)
End Sub
Now the consumer may override OnMenuShow which would bypass your raiseevent statement without you needing to "check" anything.
I found that Hans' answer reponse fit my question the best, and had he left it in an answer I would have marked his as answered. I will leave how I ended up coding this for future refrence.
Public Event MenuShow As EventHandler(Of MenuShowEventArgs)
Public Overridable Sub OnMenuShowEvent()
Dim args As New MenuShowEventArgs(False, "Control")
RaiseEvent MenuShow(Me, args)
if args.handled then return
'DO WORK
End Sub