This is something I have noticed over the years but never bothered with it before. When opening WinForms forms in designer view, VS sets some forms to an unsaved state immediately. This only happens with some forms with a slightly complex hierarchy.
The trouble is, whenever this happens, something about the form has been changed (mostly sutble changes). Usually the alignment of a nested control with anchor properties set. In this particular case, I have SplitPanel with a nested GroupBox with a nested PropertyGrid control.
So every time I run the open the form and save it, this annoying change appears in runtime and can be seen in the designer as well. Have others noticed similar behavior? If so, anyone find a cause and workaround?
Related
I would like to know if there is a way to manipulate an App's UI live while running?
I am not a designer and I have many problems sometimes regarding matching colours etc.
The next problem is that anytime I would like to change e.g. the colour of a control I have to quit the App then go to VS2012, apply my changes, build and execute it again to see simple changes.
I know that I see any changes in the designer but I have to see the resulting screen to get an impression of the whole.
Is there a way to achieve this?
Add a secret keypress while Debug flag is set, that raises a form and allows you to select controls and expose a property sheet for them. Be a bit of work to get right, and a good stick of code even using reflection. Might be better off with a storyboard type app to do your designing.
Unlike styles in WPF which can be dynamically adjusted (which made this type of run-time adjustment simple), there isn't as elegant of a solution for Windows Store apps. Ideally, you'd have all of your UI and colors, etc. defined in XAML files and not settable through other means (as it becomes a longer term maintenance issue).
I'd suggest just adding enough test data and configuration so that you can see the look and feel of the pages (with colors, etc.) at design-time. Blend and Visual Studio are now quite good at showing a very reasonable near final rendering of the elements of the application. It's generally not too difficult to do anymore.
One thing I've done in the past was to make a single page/form that contained all of the styles and controls in a large scroll viewer. Then, we set it so it was configurable to the be the first thing to run. The tweak/build cycle was pretty fast, and the results were still very manageable.
Anyone come up with a way that I can design a panel without a form?
On the surface usercontrol doesn't seem the way to go.
Background:
I come from a text editor world and VS is new to me. We did everything with panels instead of forms. So open for learning. Specifically have a base class panel (ExtendedPanel) that defines some basic controls: Cancel, Save, Save and Close. This ExtendedPanel then will be used for ClientExtendedPanel that is tied to a bindingsouce clientBindingSource. This is all tied to my entity framework model. So I will add, edit and delete sql datarows for my Client table. If no changes have happened by Save button will not be enabled. If I make a change but hit cancel it will warn me. I've done all this before but since I left that company I don't have access to the code base and they didn't use VS (text editor only)so it wasn't really transportable anyway.
All that background so I can ask: Is usercontrol the way to go, or is there something that will allow me to visually add controls to a panel like it is a form?
Yes, a UserControl provides a form-like canvas in the designer for you to add other controls (buttons, etc).
You can do this too by inheriting a panel and writing the code to add the buttons and wire their events, etc, but you won't get the designer support.
I am creating many usercontrols in an windows application in C# 3.5. I want to copy any usercontrol and paste it on another location of the MDIForm. Similarly in case of Cut option. I am using these three options in a contextmenustrip. And theses options are visible when I right click on the usercontrol. Can anyone tell me how It will be done at run time?
That requires giving the controls a new Parent. Explicitly supported by Winforms, they can even have no parent, quite a trick. You can do it directly by assigning the Parent property. Or by adding the control to another Controls collection, it will be automatically removed from the one it was in before.
Be careful, this flexibility comes with a price. It is also a source of a nasty leak that can crash your program after a while. That's caused by the no-parent trick, otherwise triggered by a Cut without a subsequent Paste. If you use Controls.Remove() or Controls.Clear() then the control is moved to the 'parking window', an invisible window created by the Winforms plumbing that acts as a temporary host. If you then don't either move the control to another parent or forget to call its Dispose() method then the control will live forever. Until your program runs out of resources or the user terminates the program.
The out of resources bomb ("cannot create window") typically happens after a few hours so is easily missed when debugging. You can see it in TaskMgr.exe, Processes tab. View + Select Columns and tick USER objects. Also tick GDI Objects and Handles to feel good about your program not leaking.
If you put the controls on a Panel then you can move them all together with just a single line of code by moving the panel.
You could remove the control from the ControlCollection in case of cut and cache it to add that control to some other form when pasted like you could do
panel1.Controls.Add(newPanelButton);// To add, you might have to change the control `Location` as per your need
panel1.Controls.Remove(newPanelButton);//To remove
In case of having cut/copy effect on the same form you could just change the Location of the control to the new location where you want to paste that control.
Ok, I've solved my problem but I don't know why one type of control works and another doesn't.
The scenario: I'm working on a custom wizard style page design that was originally done completely with UserControls in C# ASP.Net 4.0. The step that you are viewing is controlled on server side via control visibilty.
My problem: I dislike the UserControls and want to use WebControls as much as possible, though it's not worth my effort to redo the entire thing with WebControls, and new controls are needed to expand the functionality.
My original solution: I initially started creating WebControls as needed. This worked fine until I got 2 steps away from a given WebControl, where it lost it's ViewState. At least I believe that is what happened. It was a CheckBoxList and as soon as I was 2 steps away, the ListItems disappeared.
The final solution: Recreating the same control as a UserControl I always have access to the CheckBoxList Items.
This all seems fairly logical. If a control or one of it's parent's is not visible, it won't be included in the ViewState data. I guess the real question is, why does UserControl work?
I'm writing an application that is basically just a preferences dialog, much like the tree-view preferences dialog that Visual Studio itself uses. The function of the application is simply a pass-through for data from a serial device to a file. It performs many, many transformations on the data before writing it to the file, so the GUI for the application is simply all the settings that dictate what those transformations should be.
What's the best way to go about designing/coding a tree-view preferences dialog? The way I've been going about it is building the main window with a docked tree control on the left. Then I have been creating container controls that correspond to each node of the tree. When a node is selected, the app brings that node's corresponding container control to the front, moves it to the right position, and maximizes it in the main window. This seems really, really clunky while designing it. It basically means I have tons of container controls beyond the edge of the main window during design time that I have to keep scrolling the main window over to in order to work with them. I don't know if this totally makes sense the way I'm writing this, but maybe this visual for what I'm talking about will make more sense:
Basically I have to work with this huge form, with container controls all over the place, and then do a bunch of run-time reformatting to make it all work. This seems like a lot of extra work. Am I doing this in a totally stupid way? Is there some "obvious" easier way of doing this that I'm missing?
A tidier way is to create separate forms for each 'pane' and, in each form constructor, set
this.TopLevel = false;
this.FormBorderStyle = FormBorderStyle.None;
this.Dock = DockStyle.Fill;
That way, each of these forms can be laid out in its own designer, instantiated one or more times at runtime, and added to the empty area like a normal control.
Perhaps the main form could use a SplitContainer with a static TreeView in one panel, and space to add these forms in the other. Once they are added, they could be flipped through using Hide/Show or BringToFront/SendToBack methods.
SeparateForm f = new SeparateForm();
MainFormSplitContainer.Panel2.Controls.Add(f);
f.Show();
Greg Hurlman wrote:
Why not just show/hide the proper container when a node is selected in the grid? Have the containers all sized appropriately in the same spot, and hide all but the default, which would be preselected in the grid on load.
Unfortunately, that's what I'm trying to avoid. I'm looking for an easy way to handle the interface during design time, with minimal reformatting code needed to get it working during run time.
I like Duncan's answer because it means the design of each node's interface can be kept completely separate. This means I don't get overlap on the snapping guidelines and other design time advantages.
I would probably create several panel classes based on a base class inheriting CustomControl. These controls would then have methods like Save/Load and stuff like that. If so I can design each of these panels separately.
I have used a Wizard control that in design mode, handled several pages, so that one could click next in the designer and design all the pages at once through the designer. Though this had several disadvantages when connecting code to the controls, it probably means that you could have a similar setup by building some designer classes. I have never myself written any designer classes in VS, so I can't say how to or if its worth it :-)
I'm a little curious of how you intend to handle the load/save of values to/from the controls? There must be a lot of code in one class if all your pages are in one big Form?
And yet another way would of course be to generate the gui code as each page is requested, using info about what type of settings there are.