Written a quick subroutine in a class to move controls from one Panel to another in VB.NET, which seemed simple enough:
Public Sub Move(ByRef OldPanel As System.Windows.Forms.Panel)
Dim panelControl As System.Windows.Forms.Control
For Each panelControl In OldPanel.Controls
MessageBox.Show(panelControl.Name) 'Debugging
OldPanel.Controls.Remove(panelControl) 'Fairly certain this line makes no difference
NewPanel.Controls.Add(panelControl)
Next
End Sub
The problem is, it only moves about half the controls. The other panels aren't picked up by the loop at all and remain bound to OldPanel. I have verified that the controls are definitely part of the OldPanel (and not just visually floated above it).
For example, if there are 6 controls on the panel, MessageBox.Show(panelControl.Name) only feeds back 3 of them, and only those 3 controls move. This is... baffling.
I wrote a similar debugging loop inside the form class _Load event itself and this correctly picks up all 6 controls on the panel:
Dim panelControl As System.Windows.Forms.Control
For Each panelControl In Me.Panel1.Controls
MessageBox.Show(panelControl.name)
Next
Any ideas?
A common solution to this type of problem is to loop backwards over the collection. Then when you remove items it doesn't affect the index of the items you haven't seen yet:
Public Class Form1
Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
MoveControls(Panel1, Panel2)
End Sub
Public Sub MoveControls(ByVal OldPanel As Panel, ByVal NewPanel As Panel)
Dim ctlCount As Integer = OldPanel.Controls.Count - 1
For i As Integer = ctlCount To 0 Step -1
NewPanel.Controls.Add(OldPanel.Controls(i))
Next
End Sub
End Class
You are changing the collection while using for each to loop through it; that is asking for trouble: once the foreach is started and acquired the enumerator the enumerator is tied to the collection as it was at the start.
One way to solve this is by first looping and collecting a list of controls to be deleted.
Then loop the list and remove these controls.
Another way is to use for which doesn't create an enumerator.
Note that your code will not work if a control is nested within another control.
Related
I am looking for a way to prevent user form controls from appearing one by one when I'm programmatically adding them and for ways to enhance application performance and visual appeal.
Say, I have a Panel_Top in which I programmatically add comboboxes. What is happening is that they appear one by one as they are created and I am looking for a way to suspend the refreshing of the panel and or user form to make all of those programmatically added comboboxes to appear at the same time and faster than it happens right now.
I've tried suspendlayout which doesn't do anything for me or maybe I'm doing it wrong.
MyForm.PanelTop.SuspendLayout = true
And also I've tried to set the Panel_Top to invisible like:
MyForm.Top_Panel.visible = false
Which kind of sorta looks and performs better, or it might be a placebo.
What is the correct approach to this problem?
PS: I do have form set to doublebuffer = true, if that matters
What I tend to do is create a loading modal to appear on top of the form rendering the controls that need to be created/made visible, this can optionally have a progress bar that gets incremented as the control is created/shown. With the loading modal running, the container that needs to add the controls starts with SuspendLayout, adds the controls, and then finished with ResumeLayout.
This makes it so that controls are added/shown while giving the user a visual indicator that something is going on behind the scenes.
Here is a phenomenal example of a loading modal: https://www.vbforums.com/showthread.php?869567-Modal-Wait-Dialogue-with-BackgroundWorker and here is an example of using it:
Private ReadOnly _controlsToAdd As New List(Of Control)()
Private Sub MyForm_Show(sender As Object, e As EventArgs) Handles MyBase.Shown
Using waitModal = New BackgroundWorkerForm(AddressOf backgroundWorker_DoWork,
AddressOf backgroundWorker_ProgressChanged,
AddressOf backgroundWorker_RunWorkerCompleted)
waitModal.ShowDialog()
End Using
End Sub
Private Sub backgroundWorker_DoWork(sender As Object, e As DoWorkEventArgs)
Dim worker = DirectCast(sender, BackgroundWorker)
For index = 1 To 100
_controlsToAdd.Add(New ComboBox() With {.Name = $"ComboBox{index}"})
worker.ReportProgress(index)
Threading.Thread.Sleep(100) ' Zzz to simulate a long running process
Next
End Sub
Private Sub backgroundWorker_ProgressChanged(sender As Object, e As ProgressChangedEventArgs)
Dim percentageCompleted = e.ProgressPercentage / 100
' do something with the percentageCompleted value
End Sub
Private Sub backgroundWorker_RunWorkerCompleted(sender As Object, e As RunWorkerCompletedEventArgs)
PanelTop.SuspendLayout()
PanelTop.Controls.AddRange(_controlsToAdd.ToArray())
PanelTop.ResumeLayout()
End Sub
SuspendLayout() is the correct way to handle this with WinForms.
But first of all, this is a function you call, and not a flag you set.
Secondly, don't forget to call ResumeLayout() at the end of the changes.
Finally, you need to ensure you only call them once when you start to change around the controls in the panel and then again at the very end. If you use them with every control you won't get any benefit.
So the pattern might look something like this:
Public Sub SomeMethod()
PanelTop.SuspendLayout() ' Prevent the panel from updating until you've finished
' Make a bunch of changes
PanelTop.Controls.Clear()
For Each ...
PanelTop.Controls.Add( ... )
Next
PanelTop.ResumeLayout() ' Allow the panel to show all the changes in the same WM_PAINT event
End Sub
You also need to ensure you don't have anything in there like DoEvents()/Invalidate() that might invoke the windows message loop and cause the form to redraw itself.
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).
In my program (Winforms), i use usercontrols as pages. I do this in the following way:
I have a panel on my Form1 in which i load usercontrols, on these usercontrols are my actual controls (buttons, labels, checkboxes etc). So actually i'm using the user controls as "sub" pages in my form.
The usercontrols are declared at the start of runtime, so they are "live" when i load them into the panel. This has allways worked fine, untill i ran into a problem yesterday.
Yesterday I used a datagridview on one of those usercontrols and during the ParentChanged of this control i call a Sub which changes the backcollor of this data grid view. (The sub itself is a public sub which is located in a module)
Like this:
Private Sub Init_ParentChanged(ByVal sender As Object, ByVal e As System.EventArgs) Handles MyBase.ParentChanged
GetRecipe(RecipeDGV, "Bla")
End Sub
Public Sub GetRecipe(ByVal Data As DataGridView, ByVal RecipeID As String)
For r As Integer = 0 To Recipe_Mem.Rows.Count - 1
For c As Integer = 0 To Recipe_Mem.Columns.Count - 1
Data(c, r).Style.BackColor = getPresetColorByID(CInt(Data(c, r).Value))
Data(c, r).ToolTipText = getPresetNameByID(CInt(Data(c, r).Value))
NEXT
NEXT
End Sub
When i run my program, i can see that my dgv gets the data from the database (which happens in the same Sub). But there is no color change in the cells.
Now, something i've noticed is that when i add a button to the user control, and use the click event of this button to call the same sub for the coloring, it does work).
Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
GetRecipe(RecipeDGV, "Bla")
End Sub
Any idea why this works on a button click event, but it doesn't in the usercontrol parent changed event? it looks like during the parent changed event there is some kind of repaint event of the dgv. how do i solve this?
Have you tried wrapping the gridview in an ajax control ( with triggers on the ParentChanged event?
I'm a little puzzled by the "RecipeID" argument being passed as it isn't used.
VB2010. I must be missing something because I couldn't find a solution after searching for an hour. What I want to do is simple. In my app I want to display a modeless form so that it is floating while the user can still interact with the main form.
dim f as New frmColors
f.Show(Me)
But I only want one instance of the form at any time. So how can I prevent more than once instance being displayed, and if there is one instance then just give it focus?
Does something like this work for you, if the form is already visible you can not do a Show, you can just do a BringToFront, also you can check to see if the Form has been disposed so you can New up another one.
Public Class Form1
Dim f As New frmColors
Private Sub Button1_Click(sender As System.Object, e As System.EventArgs) Handles Button1.Click
If f.IsDisposed Then f = New frmColors 'To handle user closing form
CheckForm(f)
End Sub
Private Sub CheckForm(frm As Form)
If frm.Visible Then
frm.BringToFront()
Else
frm.Show(Me)
End If
End Sub
End Class
Make your form follow the singleton pattern. I can't vouch for this sample, but from the text it appears to do what you want.
I created a groupbox and then populate it with buttons during runtime. I also created a button, say Button1 to loop through the groupbox and delete those buttons. Here's my code
for Button1:
Public Sub removeControls()
For Each ctrl As Control In GroupBox1.Controls
GroupBox1.Controls.Remove(ctrl)
ctrl.Dispose()
Next
End Sub
Private Sub Button1_Click(ByVal sender As System.Object, ByVal e As System.EventArgs) Handles Button1.Click
removeControls()
End Sub
When executed, it only removes some of the controls inside the GroupBox1, not all. Can you explain what is missing in my code to make it work? Thanks.
When you delete controls in a For Each loop, you're actually modifying the collection that you're trying to loop through. When you remove the first item in the collection, the second item moves up to become the first. But now, when you reach the second index of your loop, the third item is in its place. You've effectively skipped removing the second item, and only removed the first and third. And so on through the entire loop.
Instead, you need to loop through the controls in reverse order and remove the item at each index. By starting to removing items from the end, you won't affect the order or position of the items.
So, just change your method to the following:
Public Sub RemoveControls()
For i As Integer = (GroupBox1.Controls.Count - 1) To 0 Step -1
Dim ctrl As Control = GroupBox1.Controls(i)
GroupBox1.Controls.Remove(ctrl)
ctrl.Dispose()
Next i
End Sub
You are changing the collection as you are itterating through it, and that should not be done.
Rather use something like
For i As Integer = GroupBox1.Controls.Count - 1 To 0 Step -1
Dim ctrl As Control = GroupBox1.Controls(i)
GroupBox1.Controls.Remove(ctrl)
ctrl.Dispose()
Next