WindowState Changed

[JaedenRuiner]

It appears that contrary to previous incarnations of VB the only way to truly detect changes to the window state is by listening to the SizeChanged() event and having a "stored" variable that retains the "old state" and comparing it to the new state. Is this accurate or is there a better way within the Windows Forms class to determine when the user maximizes/minimizes/restores the form.

Thanks

 

[JuggaloBrotha]

That's pretty much it, it would be nice if there was a WindowStateChanged event by default for a form. If you want that automatically included, you could create a custom control that inherits the standard form and create the event and whatnot. Then change all of your forms to your new one (barely any code changes to switch from the standard to yours)

Something like this:

Option Explicit On
Option Strict On
Option Infer Off

Public Class StateChangedForm
    Inherits System.Windows.Forms.Form

    Private _WindowState As FormWindowState

    Public Event WindowStateChanged As EventHandler

    Public Shadows Property WindowState() As FormWindowState
        Get
            Return MyBase.WindowState
        End Get
        Set(ByVal value As FormWindowState)
            If Me.WindowState <> value Then
                MyBase.WindowState = value
                Me.OnWindowStateChanged(EventArgs.Empty)
            End If
        End Set
    End Property

    Protected Overridable Sub OnWindowStateChanged(ByVal e As EventArgs)
        RaiseEvent WindowStateChanged(Me, e)
    End Sub
End Class

I haven't tested this yet, so it may not work 100% correctly yet.

 

[jmcilhinney]

Rather than shadowing the WindowState property, I'd be inclined to override the OnSizeChanged and OnLocationChanged methods and test for a change to the WindowState property there. Shadowing is best avoided if at all possible because, if you ever cast an instance as the base type, all shadowed members are lost.

 

[JuggaloBrotha]

Rather than shadowing the WindowState property, I'd be inclined to override the OnSizeChanged and OnLocationChanged methods and test for a change to the WindowState property there. Shadowing is best avoided if at all possible because, if you ever cast an instance as the base type, all shadowed members are lost.

OnSizeChanged? OnLocationChanged?

I can do these though:

    Private Sub StateChangedForm_LocationChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.LocationChanged
        Me.OnWindowStateChanged(EventArgs.Empty)
    End Sub

    Private Sub StateChangedForm_SizeChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles Me.SizeChanged
        Me.OnWindowStateChanged(EventArgs.Empty)
    End Sub

 

[JohnH]

OnSizeChanged?

When extending a class it is more common to override the On... method than to subscribe to the event it raises. This give more control to do things before and after the event is raised, you can even suppress it by not calling the base method if it doesn't disrupt base functionality.

Protected Overrides Sub OnSizeChanged(ByVal e As System.EventArgs)
    MyBase.OnSizeChanged(e)
    If Me._WindowState <> Me.WindowState Then
        Me._WindowState = Me.WindowState
        Me.OnWindowStateChanged(EventArgs.Empty)
    End If
End Sub

 

[jmcilhinney]

As JohnH says. One thing that overriding the event raising methods does for you is that it gives you the option of raising the WindowStateChanged event either before or after the other events. In the code JohnH posted the WindowStateChanged event will be raised AFTER the SizeChanged event. If you change it to this:

Protected Overrides Sub OnSizeChanged(ByVal e As System.EventArgs)
    If Me._WindowState <> Me.WindowState Then
        Me._WindowState = Me.WindowState
        Me.OnWindowStateChanged(EventArgs.Empty)
    End If

    MyBase.OnSizeChanged(e)
End Sub

the WindowStateChanged event will be raised first.

It is generally considered incorrect for an object to handle its own events. Overriding the methods that raise those events is considered the correct way to do it. This is often not done in forms because the IDE makes it too easy to create event handlers but it really should be done there too.

 

[JuggaloBrotha]

I vaguly remember seeing that stuff in the VS 2003 IDE (Code editor) but VS 2005 and 2008 doesn't show those in the drop downs at the top of the code window where I think VS 2003 had them.

Where can those subs/events be selected from when inheriting from a control in the IDE?

 

[JohnH]

Where can those subs/events be selected from when inheriting from a control in the IDE?

Write "overrides " (or part of it) and choose from the intellisense list.