Trying to understand the nature of inherited windows forms....
-
I’m working on an application that uses an inherited windows form. I’ve accepted the forms designer bugs that accompany using inherited forms in Visual Studio 2012, but I’m trying to understand the nature of the inherited form itself. My original (parent) form code is relatively simple, but contains a small loop that updates a label control on the form with the current time. This form is then inherited by my other forms so that they will always display the current time. When I look at the parent form in the forms designer, it displays as it should, with whatever default text I’ve placed into the label control. However, when I look at any of my child/descendant forms their label is being updated with the current time, i.e. the code of the original parent form is compiled and running, even while viewing the descendant form in the VS Forms Designer. This seems strange to me—shouldn’t the descendant forms be inheriting the source code *only*, but not actually running it until the project is compiled and run?
-
I’m working on an application that uses an inherited windows form. I’ve accepted the forms designer bugs that accompany using inherited forms in Visual Studio 2012, but I’m trying to understand the nature of the inherited form itself. My original (parent) form code is relatively simple, but contains a small loop that updates a label control on the form with the current time. This form is then inherited by my other forms so that they will always display the current time. When I look at the parent form in the forms designer, it displays as it should, with whatever default text I’ve placed into the label control. However, when I look at any of my child/descendant forms their label is being updated with the current time, i.e. the code of the original parent form is compiled and running, even while viewing the descendant form in the VS Forms Designer. This seems strange to me—shouldn’t the descendant forms be inheriting the source code *only*, but not actually running it until the project is compiled and run?
smarrocco wrote:
houldn’t the descendant forms be inheriting the source code *only*, but not actually running it until the project is compiled and run?
VS is trying to compile code as you edit; that's the way it underlines stuff that the compiler is missing. What you are seeing in the designer is a preview of the form you are editing, but it will need a compiled version of the form that it is based on.
Bastard Programmer from Hell :suss: If you can't read my code, try converting it here[^]
-
I’m working on an application that uses an inherited windows form. I’ve accepted the forms designer bugs that accompany using inherited forms in Visual Studio 2012, but I’m trying to understand the nature of the inherited form itself. My original (parent) form code is relatively simple, but contains a small loop that updates a label control on the form with the current time. This form is then inherited by my other forms so that they will always display the current time. When I look at the parent form in the forms designer, it displays as it should, with whatever default text I’ve placed into the label control. However, when I look at any of my child/descendant forms their label is being updated with the current time, i.e. the code of the original parent form is compiled and running, even while viewing the descendant form in the VS Forms Designer. This seems strange to me—shouldn’t the descendant forms be inheriting the source code *only*, but not actually running it until the project is compiled and run?
Remove any functioning code from the constructors.
Public Class myForm
Inherits Form
WithEvents _tmr As System.Timers.Timer
Dim _lbDateTime As LabelPublic Sub New() End Sub Public Sub StartUI() \_tmr = New System.Timers.Timer \_tmr.Interval = 2000 \_lbDateTime = New Label Controls.Add(\_lbDateTime) \_lbDateTime.Location = New Point(5, 5) \_lbDateTime.Visible = True \_lbDateTime.AutoSize = True \_tmr.Start() End Sub Private Sub Tick() Handles \_tmr.Elapsed \_tmr.Stop() UpdateTimer(Date.Now) \_tmr.Start() End Sub Private Sub UpdateTimer(ByVal time As String) If \_lbDateTime.InvokeRequired Then \_lbDateTime.Invoke(New Action(Of String)(AddressOf UpdateTimer), time) End If \_lbDateTime.Text = Date.Now End Sub
End Class
In the Child form's constructor add the call to StartUI()
Public Sub New()
' This call is required by the designer. InitializeComponent() ' Add any initialization after the InitializeComponent() call. StartUI()
End Sub
regs ron O.
-
Remove any functioning code from the constructors.
Public Class myForm
Inherits Form
WithEvents _tmr As System.Timers.Timer
Dim _lbDateTime As LabelPublic Sub New() End Sub Public Sub StartUI() \_tmr = New System.Timers.Timer \_tmr.Interval = 2000 \_lbDateTime = New Label Controls.Add(\_lbDateTime) \_lbDateTime.Location = New Point(5, 5) \_lbDateTime.Visible = True \_lbDateTime.AutoSize = True \_tmr.Start() End Sub Private Sub Tick() Handles \_tmr.Elapsed \_tmr.Stop() UpdateTimer(Date.Now) \_tmr.Start() End Sub Private Sub UpdateTimer(ByVal time As String) If \_lbDateTime.InvokeRequired Then \_lbDateTime.Invoke(New Action(Of String)(AddressOf UpdateTimer), time) End If \_lbDateTime.Text = Date.Now End Sub
End Class
In the Child form's constructor add the call to StartUI()
Public Sub New()
' This call is required by the designer. InitializeComponent() ' Add any initialization after the InitializeComponent() call. StartUI()
End Sub
regs ron O.
While I appreciate the effort bojammis, It's more about understanding the issue and why the parent code compiles, or better yet, if it can be avoided with some IDE setting. There are a number of ways to avoid the problem, including using the DesignerMode flag to determine if code should run. Unfortunately it isn't only constructors that run. Load() and other events are triggered at undesired times as well, complicating the code, when the whole purpose of the inherited form should be for the simplification of the code. Also for clarification, my code does a lot more than build a timer--I simplified my description for this post. There are several independent background tasks which are being launched that now all have to monitor if the IDE is running them, or the designer.
-
While I appreciate the effort bojammis, It's more about understanding the issue and why the parent code compiles, or better yet, if it can be avoided with some IDE setting. There are a number of ways to avoid the problem, including using the DesignerMode flag to determine if code should run. Unfortunately it isn't only constructors that run. Load() and other events are triggered at undesired times as well, complicating the code, when the whole purpose of the inherited form should be for the simplification of the code. Also for clarification, my code does a lot more than build a timer--I simplified my description for this post. There are several independent background tasks which are being launched that now all have to monitor if the IDE is running them, or the designer.