A Quick Note
I've tried to be as thorough as possible with my question but you may still need additional clarification; if this happens to be the case, feel free to comment your concerns and I will update the post to answer them as best as I can.
I came across a rather odd issue yesterday when toggling controls on my form. I have a period of loading on FormShown and all controls but the loading display should be hidden. The toggle works to turn visibility off for everything but the loading display, but when loading completes only some of the controls are visible.
I stepped through the code that turns everything back to visible and ensured that everything is indeed being set to Visible = true. I think it may have something to do with the Dock property on the controls, or maybe the TabIndex or something similar but I'm having trouble tracking the underlying issue down.
This is the code I use to toggle the control visibility:
private void ToggleAllControlVisibility() {
foreach (Control c in Controls)
ToggleControlVisibility(c);
}
private void ToggleControlVisibility(Control c) {
if (c.Name == "loadingContainer")
return;
if (!(c is SplitContainer || c is SplitterPanel))
c.Visible = !c.Visible;
foreach (Control child in c.Controls)
ToggleControlVisibility(child);
}
It is a recursive toggle in which all child controls are also toggled. The ToggleAllControlVisibility method is called before loading begins, and again after loading completes.
A More Detailed Look
Now that you know the problem, there are certain controls in particular that I know do not show (at least the way they should). Take the following control tree for example:
pTimePanel (Panel)
timeSlider (TrackBar)
lblStartTime (Label)
lblStopTime (Label)
Out of the controls above, only the pTimePanel actually displays in the foreground. I believe its child controls may be displaying behind it somehow because as I step through the code and it reaches the lblStartTime control, I can briefly see the outline of the label (no content) and then when it moves to the next control it's gone. The timeSlider control doesn't seem to show the same behavior but it does get back to Visible = true.
The full tree from form to the above controls (with docking properties) is as below:
splitContainer : Dock-Fill
panel1 (SplitterPanel)
loadingPanel (Panel) : Dock-Fill
pTimePanel (Panel) : Dock-Bottom
pTimeLabels (Panel) : Dock-Bottom
lblStartTime (Label) : Dock-Left
lblStopTime (Label) : Dock-Right
timeSlider (TrackBar) : Dock-Fill
Notes
Some of these may be less helpful than others, but as I think of things that may help clarify what's going on, I'll add them here.
When visibility is toggled in either direction, the Resize event on the loadingPanel is raised.
Question
What could possibly be occurring to make this odd behavior possible?
It turns out that this was related to the order in which the controls were added to the form. Due to some copying and pasting controls a while back things ended up in an improper order. I had to rebuild the form from scratch to get any toggling to actually work. Once I rebuilt the form, all of the available options for toggling began working the way I expected them to.
Related
I am facing an issue while running through all the User Controls in my Windows form.
I am creating a Windows Form that has the following features:
The Main form has 3 User Controls embedded in it
The Main form also has a combo box. Selecting a particular value in the Combo box will bring the corresponding User Control to the front.
Each User Control has two Check boxes as well as two Combo boxes.
The User can summon each User Control through the Main Form's combo box and check the check boxes and/or modify the combo boxes inside each User Control
Once this is done, there is a button, which on being pressed, executes the following code. This code is supposed to check which check boxes have been checked from every User Control, and execute some functionality :
private void button1_Click(object sender, EventArgs e)
{
foreach (Control c in this.Controls)
{
if (c is UserControl)
{
foreach (Control ctl in c.Controls)
{
if (ctl is CheckBox && (ctl as CheckBox).Checked)
{
Indicator.Text = "It's in";
}
}
}
}
//Some other code after this
}
Here, I have included a Text Box called "Indicator" that shows whether the compiler has entered a particular "for" loop or "if" block. And I'm observing that the innermost "if" alone is not getting executed.
Could someone point out why exactly this is happening?
You need a recursive algorithm,
void ProcessControls(Control ctrlContainer)
{
foreach (Control ctrl in ctrlContainer.Controls)
{
if (ctrl is CheckBox && (ctrl as CheckBox).Checked)
{
Indicator.Text = "It's in";
}
if (ctrl.HasChildren)
ProcessControls(ctrl);
}
}
I do think you might be better off adding some functionality to your user control so it can describe the state of its own checkboxes rather than going digging inside it to find it and do logic. Generally in OO programming, when we encapsulate things within a class, we also provide general purpose accessors "visible to the outside" to describe the internal state of affairs, rather than letting external code interests go poking around inside class to find out what they want
At some point in time you've added these usercontrols to the form either directly in the designer, or programmatically. In the first case they will have their own name:
var u1 = usercontrol1.GetCheckboxStateArray();
var u2 = usercontrol2.GetCheckboxStateArray();
Etc
Or maybe you added them programmatically, in which case it would make sense to keep track of them in a list as you're adding them:
protected List<UserControl> _ucList = new List<UserControl>();
...
foreach(var result in somedatabasequery){
var uc = new UserControl(result.Whatever);
this.Controls.Add(uc);
_ucList.Add(uc);
}
Then this list can be iterated. Sure you could argue that "well .Controls is a collection too, so why add them to another list when they're already in an accessible collection" - for the reasons you're here; .Controls is a general purpose description of the hierarchy of all controls on a form, it contains stuff we don't want and is hard to iterate. This List is purely and simply all and only the stuff we're interested in
As an aside, the UI you have described is atypical. The more usual way of hiding and showing controls under the selection of something that holds a bit of text would be a TabControl. It might be easier to loop through too, if you will persist with this "search for UserControls in a collection of controls" method - tabcontrols have tabpages, tabpages would probably have a .Controls that just contains your UserControl. The tabpage intrinsically takes care of showing and hiding controls as pages are clicked on which could simplify your code
Thanks to everyone for the answers. As it happens, the issue was hiding in plain sight, right under my nose. In each of the User Controls, I had placed the Checkboxes and Combo Boxes inside a Group Box. It completely slipped my mind, so much so that I didn't even mention them in my question.
Thus, as #Caius had suggested in the comments, the code wasn't functioning because I had not addressed the Group Box Container holding these Controls. Once I removed the Group Boxes (used only for aesthetic purpose), the code started functioning properly.
I have a form with labels and other components, picture boxes, panels, etc.. When I am doing Form.enabled = false; (because I have another form on top of it) the labels are not showing even though the visibility of the components is set to true; Any ideas?
I didn't include code because I'm not sure what to include!
Thanks for any help!
Edit: After what Joel Etherton said, I tried using this event:
private void label1_VisibleChanged(object sender, EventArgs e)
{
label1.Visible = true;
}
This is giving me a StackOverflowException.. maybe this is infinitely trying to override the parent control visibility.. What can I do please?
Check the element's parent objects (and follow it up the tree). Usually this is caused by a parent being set to Visible = false;. Visibility settings for a particular control will still register as true, but when the page is actually rendered it will stop producing controls at any parent level whose visibility is false.
Edit:
First you should find the root cause of the problem. This isn't a code issue so much as an expectation issue. A control is expected to be visible, but you've created a condition where that is not possible. I think you'd be better served by trying to find out what condition is causing a parent control to have a false visibility. Most likely you'll find either there is a logical problem with forcing a parent's visibility or a design problem where your "visible" control is being placed in the wrong root container. However, if you just want to brute force the visibility of parents you can have a recursive method do it:
private static void SetAllParentVisibility(bool visible, Control ctrl)
{
ctrl.Visible = visible;
if (ctrl.Parent != null)
SetAllParentVisibility(visible, ctrl.Parent);
}
Also, treat the above method as psuedo-code. I haven't tested it out, and the type Control may need to be altered to be able to adjust to different parent types.
In a program I have written users can add controls to the form and move them around and set some properties in a pseudo design mode. I want to be able to lock all these controls into one location when they press a button to switch to "data mode". How can I do this? I wanted to do be able to loop through all the controls and use the Lock Property but I noticed it didn't show up in intellisense.
Thanks!
The Locked property is not a real property -- it is one which is added in by the Windows Forms designer (like the Generate Member and Modifiers "properties"). You would therefore need to simulate it yourself, either at the form level or (if required) at the control level (say with a dictionary of which controls are locked), and manually check it in the code you've written for moving controls around.
I am assuming by "pseudo-design mode" you do mean that your application is in a run-time state, and the end-user is experiencing a "virtual design mode" : please correct me if I am wrong.
But, I am assuming you are referring to the design-time 'Locked property of controls, and that you wish to "emulate" this at run-time ... correct ?
I'm also assuming you are attaching mouse up/down/move handlers to the controls you do allow to move around, probably by looping through all, or a subset of, the controls on the form (or a collection you are maintaining of controls allowed to be moved).
If my assumptions are correct, I would go for removing the event handlers that enable moving when you need to disable control movement, then restoring those event handlers when you need to allow controls to be moved again.
One main reason being that it is, imho, "best practice" to control event-handling rigorously (leaving event handlers "in-place" can interfere with object disposal ... although that may, in no way, apply to your scenario here).
One more idea : you have an "invisible" Panel docked 'fill to the Form : on this panel are all controls that can be moved : this may allow you to more easily "narrow your focus" on which controls you "spend" this extra code on. The drawbacks in using this approach are usually :
if you use hostingForm.ActiveControl to determine which control got the mousedown (and, thus, can then be moved) : you'll find some controls, like labels, and pictureboxes, do not become the activecontrol of the form when clicked, but most do.
you have a "z-order" thing to think about since a control not in your panel encapsulating the controls you wish to allow to move sent behind the pseudo-transparent panel will be hidden.
For these reasons, imho, I think disabling and re-enabling event handler attachments is best, most simple, and since it can be done when the controls are "down-cast" to their control "identity" :
private void enableControlsMove()
{
foreach (Control theControl in panel1.Controls)
{
Console.WriteLine(theControl.Name);
theControl.MouseDown += new MouseEventHandler(theControl_MouseDown);
theControl.MouseUp += new MouseEventHandler(theControl_MouseUp);
theControl.MouseMove += new MouseEventHandler(theControl_MouseMove);
}
}
private void disableControlsMove()
{
foreach (Control theControl in panel1.Controls)
{
Console.WriteLine(theControl.Name);
theControl.MouseDown -= theControl_MouseDown;
theControl.MouseUp -= theControl_MouseUp;
theControl.MouseMove -= theControl_MouseMove;
}
}
I use it this way.
best, Bill
Locking controls prevents them from
being dragged to a new size or
location on the design surface.
However, you can still change the size
or location of controls by means of
the Properties window or in code.
MSDN
I guess it's a visible-to-designer-only property. I think you'd have to implement your own freeze mechanism - a little flag to toggle between Design and Use modes.
Update: It seems that custom designer classes can add properties to controls based on whether they are in Design Mode or not.
More details available here if you intend to take the VS architectural hammer path. In any case, worth 10 mins of reading time.
Custom Design-time Control Features in Visual Studio .NET - Dino Esposito
I have a control which contains a NumericUpDown. The updown is only shown when the container has focus, so the container has to be selectable (or else it could never receive focus). I want the control to behave as a single entity with regards to tab order; that is, when the user tabs to the control, it shows the updown and the updown is focused; when the user tabs away from the updown, it is as if they had tabbed away from the control.
It's easy enough to achieve the first part: in the container's OnEnter, I focus the updown. If the user tabs away without shift, it also works fine, since the next control in the tab order is the correct one. However, the previous control in the tab order to the updown is the container, since it had to be selectable; so when the user shift-tabs away from the updown, the container is selected, and therefore the updown gets selected again.
How do I select the previous control to the container control, when the user shift-tabs away from the updown?
UPDATE:
My problem isn't detecting when I need to do this - it's finding the control to send focus to.
UPDATE:
SelectNextControl only seems to work within the container's parent's controls; if the container is the only control on its parent, it doesn't change focus, even if there are other controls elsewhere in the hierarchy that ought to receive focus via tab.
if you know the direction of the tab you could use SendKeys.Send("+{TAB}"); and SendKeys.Send("{TAB}");
or you could use Control.SelectNextControl()
void UserControl1_Leave(object sender, EventArgs e)
{
this.numericUpDown1.Visible = false;
Control c = Parent.Controls[this.Name];
int i = Parent.Controls.IndexOf(c);
Parent.Controls[i - 1].Focus();
}
I've added this leave event to a custom control and its working for me. Basically when the user shift tabs away this event sets the focus to the previous control in the parent form's control collection. Don't know if its what your looking for exactly but hopefully it will send you in the right direction.
It's a hack, but you can use the OnEnter event coupled with a boolean variable. If the variable is set to true then you were already in your container and go to the previous control (which could be a property of your container control so you know where you are going).
If the variable is false, your just getting to your custom control and focus on the up/down.
On the exit of the container, set the variable back to false.
I'm sure there's something simpler out there, but offhand this is the quickest thing I can think of.
Actually this seems to be the default behavior for me?
I'm working on a C#.Net application which has a somewhat annoying bug in it. The main window has a number of tabs, each of which has a grid on it. When switching from one tab to another, or selecting a different row in a grid, it does some background processing, and during this the menu flickers as it's redrawn (File, Help, etc menu items as well as window icon and title).
I tried disabling the redraw on the window while switching tabs/rows (WM_SETREDRAW message) at first. In one case, it works perfectly. In the other, it solves the immediate bug (title/menu flicker), but between disabling the redraw and enabling it again, the window is "transparent" to mouse clicks - there's a small window (<1 sec) in which I can click and it will, say, highlight an icon on my desktop, as if the app wasn't there at all. If I have something else running in the background (Firefox, say) it will actually get focus when clicked (and draw part of the browser, say the address bar.)
Here's code I added.
m = new Message();
m.HWnd = System.Windows.Forms.Application.OpenForms[0].Handle; //top level
m.WParam = (IntPtr)0; //disable redraw
m.LParam = (IntPtr)0; //unused
m.Msg = 11; //wm_setredraw
WndProc(ref m);
<snip> - Application ignores clicks while in this section (in one case)
m = new Message();
m.HWnd = System.Windows.Forms.Application.OpenForms[0].Handle; //top level
m.WParam = (IntPtr)1; //enable
m.LParam = (IntPtr)0; //unused
m.Msg = 11; //wm_setredraw
WndProc(ref m);
System.Windows.Forms.Application.OpenForms[0].Refresh();
Does anyone know if a) there's a way to fix the transparent-application problem here, or b) if I'm doing it wrong in the first place and this should be fixed some other way?
There are calls on classes derived from Control for this purpose. They are SuspendLayout and PerformLayout. As they are on Control and Form is derived from Control, your Form has them too.
These calls suffice for most updates but in other circumstances, just hiding the control using Visible = false can be enough. To stop the flicker during this hiding and then reshowing of the control, I usually draw the control to a bitmap which I show in a PictureBox during the update. This is useful when updating trees, tab controls, or lists (as can turning off sorting during the update in that last example).
The behavior you're describing is not normal for a .NET winforms application. The fact that you're using WndProc and sending messages in your example suggests that there is a lot of other unusual stuff going on with this form (I'm guessing there's more than one thread involved). Another possibility that is common in tabbed interfaces is that your form is simply overloaded with controls; sometimes this can cause strange behavior.
I have never witnessed or heard of anything remotely like what you describe.
You can try override the Paint method on your control that you do not want rendered and control it by some global boolean (=ignore all painting while some bool is true.)
If your control is a 3rd party, subclass it and override it there.
Then when you are satisified, set the bool to false and let the control be painted again (might have to force a paint when you turn it on again with .Refresh?)
If this is a custom control, you can try some of the control style flags: I think DoubleBuffered or AllPaintingInWmPaint might help. You can change the style bits using Control.SetStyle (which is protected, which is why you need to do it in your own custom Control class).