Develop Reference

How do I apply the Settings.settings values at design time?

I have a panel in my Form like this:
and a Panel_BackColor in project's Settings.setting file:
I can change panel back color in the Form constructor:
public partial class MainForm : Form
{
public MainForm()
{
InitializeComponent();
panel1.BackColor = UI_Settings.Default.Panel_BackColor;
}
}
All things work at runtime:
But nothing change at Design Time. How can I apply these settings at Design mode too?

I got your question, I try to handle with it when I use MetroFramework. Some changes just shown in runtime because it use another drawing technic with xml or .netframework when you use runtime code. So, I think you can't see changes in design time.

Next time try to explain a little more in details or maybe add some code or images to make us understand better.
In C# you have the property:
//Namespace: System.ComponentModel
//Gets a value that indicates whether the Component is currently in design mode.
//true if the Component is in design mode; otherwise, false.
protected bool DesignMode { get; }

I asked "not edited version" of this question on MSDN forum and got an answer within an hour.
Questions like Convert int to string? is a good questions but mine is not!
I think stackoverflow should keep a watch on it's editors and policy.
The answer:
Select your control in Form Designer (for example a button), go to Properties, (ApplicationSettings),(PropertyBinding), then bind BackColor or other property to Button_BackColor or other settings. Afterward by changing settings in Settings.settings file, all binded controls would be affected.

WinForms - how to save the combobox selection in the app's settings?

I have a combobox embedded in a toolstrip - a ToolStripCombobox instance.
The list of items is the list of values of an enum.
I'd like to be able to load/save the selection (One of the Selected[Index|Item|Text|...] properties, from/to the app's Settings "mechanism".
Ideally, I'd like to be able to do that from the designer.
Normally, hooking a control's property to a certain setting is done (in the designer) from the control's properties, under (ApplicationSettings) - but none of the SelectedXXX properties shows up in there.
FWIW, in the particular case of toostrip-bound combo-boxes, the actual SelectedXXX properties are actually found a bit deeper, at toolStripComboInstance.ComboBox.SelectedXXX.
What I have done so far is configure the binding in code:
m_runTypeCombo //the toolstrip control
.ComboBox //the actual combobox
.DataBindings.Add(
new System.Windows.Forms.Binding(
"SelectedItem",
global::JavaPad.Properties.Settings.Default,
"RunType",
true, System.Windows.Forms.DataSourceUpdateMode.OnPropertyChanged
)
);
The above works, but I was hoping for something cleaner (i.e. designer-based). If the built-in ToolStripCombobox doesn't support this, is there a (simple) way to derive my own type from that, and expose the SelectedXXX properties in such a way that it works with the Application Settings infrastructure (and its support in the designer)?

If you are willing to wrap the TooltipComboBox in your own custom control, you can do it like this:
public class MyCombo : ToolStripComboBox
{
[SettingsBindable(true)]
public int SelectedIndex
{
get { return ComboBox.SelectedIndex; }
set { ComboBox.SelectedIndex = value; }
}
}
Note that I haven't tested this beyond confirming that I can add the control to the ToolStrip, and that I can select a property - You may need to add PropertyChanged Events to make it work fully.

User Control that acts like a standard Window, only confined to a pane

I'm making a program to generate code for me, and I'm fashioning the UI after Game Maker due to how easy the interface is. It has a SplitContainer with Panel1 containing a TreeView and Panel2 containing an arbitrary amount of self-contained windows (real windows, not some hacky workaround). I wanted to use user-controls to store the controls I use to modify things, but I can't figure out any way to put it in a window inside the splitContainer's Panel2. Can anyone help me?
Here's a good example:
http://i.stack.imgur.com/CG6kO.png
Those two sprite property windows are what I'm trying to do.

i think what you are looking for is called mdi-container
however the only real mdi container i've seen so far (in .NET) is a form ... sadly no panel or something similar...
but if you just want the "window in a window" effect: simply create your new form, set the TopLevel property of that instance to false, and add the instance to your form/panel/splitcontainer/whatever like any other usual control

You could try using an MDI form and to implement your TreeView control, check out some sort of docking panel. I've used this one in the past (http://sourceforge.net/projects/dockpanelsuite/).
It is very flexible. You set up one of these dockpanel forms, docked to the left of your MDI form. It will always be "on top" and the user can resize it exactly like the splitter control on a form. If you like, it can also has an "autohide" feature which may or may not be desirable in your case.
It can then contain you treeview, which can load all the MDI Child forms you like.
You'll find you're not fighting how "Windows" really want to behave and things will run a lot more smoothly.

Put it into the Panel2's Control collection via the Add() method, apply coordinates, anchor and docking programmaticaly.

I did similar thing once, and for that reason, I have ReplaceControl method, which I paste below:
static public void ReplaceControl(Control ToReplace, Form ReplaceWith) {
ReplaceWith.TopLevel=false;
ReplaceWith.FormBorderStyle=FormBorderStyle.None;
ReplaceWith.Show();
ReplaceWith.Anchor=ToReplace.Anchor;
ReplaceWith.Dock=ToReplace.Dock;
ReplaceWith.Font=ToReplace.Font;
ReplaceWith.Size=ToReplace.Size;
ReplaceWith.Location=ToReplace.Location;
ToReplace.Parent.Controls.Add(ReplaceWith);
ToReplace.Visible=false;
}
Only thing left to do is to create some control manually on the form, as the placeholder for your Form. Use label, for example.
From How to implement a-form-inside-a-form with runtime embedded forms switching?

Help me to find a better programming approach

My application has a set of base classes derived from almost all the UI controls
XCombobox,XButton,XMenu etc. All these classes have some additional functionality apart from standard functionality (ex: Serialization capability)
I use all these controls in my test windows application.
I want to implement a concept similar to themes in my application.
Ex: Say if i need a blue background
I have a public property exposed in all controls which sets my controls
(i.e XButton and XMenu) backcolor to blue
I feel this approach is lame. Tomorrow if my manager wants some other styling.
I will have to go to every control and change the backcolor one by one ...not that i mind ;)....but this never makes me a good programmer.
Time for some application of a design pattern (strategy pattern shall i say ?)
Is there a possibility wherein i can just change in one central place and the property shall get applied to all of my UI controls ?
If yes... Please help me in realising the same.
If not ... Suggestions for some more better ideas are welcome.

Define a class that has properties for the colors (you can also add in properties for logos etc).
Then either have your constants in the code of that class, or read them in from some XML.

You answered your question already.
Define constants for styling in central properties, and use these styling constants in your UI components :).

I would use a dependency injection container such as Unity for this, it will allow you to register you theme in a single location and have all of your controls resolve the theme whenever they need it.
For example, implement a simple interface which has the properties of the theme that each control will use.
interface IXTheme {
Color BackColor { get; }
}
Wherever your control needs to fetch this, such as in OnPaintBackground, you make a simple call to fetch the color, using the CommonServiceLocator (This comes packaged with Unity already.)
protected override void OnPaintBackground(PaintEventArgs pevent)
{
Color backColor = ServiceLocator.Current.GetInstance<IXTheme>().BackColor;
///...
}
Now, you can create you theme somewhere else based on that interface.
class XBlueTheme : IXTheme {
Color IXTheme.BackColor { get { return Color.Blue; } }
}
You then register the theme with the container and use the container to resolve your form.
IUnityContainer container = new UnityContainer()
.RegisterType<IXTheme, XBlueTheme>();
IServiceLocator locator = new UnityServiceLocator(container);
ServiceLocator.SetLocatorProvider(() => locator);
XForm myForm = container.Resolve<XForm>();

From what you're saying, it seems like if you just want to change the color, the easiest thing would just be to save the color in a variable somewhere, or have some kind of initialization function that every component calls where you can specify shared things like the color.
Also, since you mentioned that you're adding additional functionality to components, you may want to use a Decorator design pattern for that purpose.

You can make something like .skin file provided in .net web projects. Or just an xml file will do; For instance,
Make a .skin file and add your controls and styling definitions there.
Add the .skin file path in some public property of your control's base class.
Add an event OnDraw, the all the controls override and color itself with the color defined in .skin.
Better try utilizing the existing .skin file; though I am not sure how would you plan to parse the .skin file.
<TextBox BackColor="Red" ForeColor="Blue"/>
<Button BackColor="White" ForeColor="Green"/>
<DropDownList BackColor="Cyan" ForeColor="Pink"/>
You can even extend the skin file by adding the cssClass property; and add styling according to css class defined in the css file.
<TextBox cssClass="TextLoginField"/>
<DropDownList cssClass="ComboLongList" />
Just thinking out loud! Btw, this article might give you an insight.

I guess the strategy pattern that you've mention fits the best.
That book Head Fisrt Design patterns describes this issue very well.
you need an interface say IStyle defined as a member of your base class so that the style behavior will be independent of your control inheritance.

How bad is the following snippet?

My question is simple: how bad is the following snippet of code? How would you do it?
CancelEventHandler _windowClosing;
private CancelEventHandler WindowClosing
{
set
{
clearEventHandlerList();
this.Closing += value;
_windowClosing = value;
/*
* if calling the method with null parameters,
* it will set up itself as the primary control on the Window
*/
_windowClosing(null,null);
}
get
{
return _windowClosing;
}
}
private readonly CancelEventHandler[] CONTROLS = null;
private int current = 0;
public InitializerForm()
{
InitializeComponent();
/*
* these are the handlers for the different controls,
* in the order of appereance to the user
*/
STATES = new CancelEventHandler[] { handler1, handler2, etc. };
WindowClosing = CONTROLS[0];
}
private void clearEventHandlerList()
{
foreach (CancelEventHandler c in CONTROLS)
{
this.Closing -= c;
}
}
private void handler1(object obj, CancelEventArgs e)
{
if (obj == null)
{
//hide every other control, but this one, also set up if necessary
}
else
{
//do something
WindowClosing = CONTROLS[++current]; // set the next control to show
e.Cancel = true;
}
}
The point would be that the code wouldn't close a form, but instead show another component on it, and the set the way to handle that (this is mobile platform, so clicking OK button on the top generates a closing event). This is because showing several forms (4 or 5) one after another to the user makes the app blink, and also very annoying, while replacing just components is much smoother. This model works, but seems very nasty, and I would like a cleaner way to handle this.
Update:
I updated the code sample so that variable names are somewhat speaky. Still, I'm convinced this is awful, (a) but not sure how much, and more importantly, (b) how to do it better.
Update 2:
So, it seems that the code is still a bit mysterious.
Now here's what the problem is:
I show the user a form, which instructs him what to do in several languages. He proceeds by clicking OK on the window. Next, I ask for his language, and then a few questions (where his/her GPS is, etc.) like this. After he could answer the questions (this shouldn't take more than a few seconds each), I show him a splash screen (I load stuff in a separate thread meanwhile), which has a picture. Showing these forms one after another makes the whole application start slow, and filled with UI lags.
Here's what I do to work around the lags: I put the content of the windows into panels, and put those panels one on another, and hide every one of them but the one that should be visible to the user. (current variable) Each of the windows does different things, so I need to change handler of the window closing event in addition. In this code the part which enables the panel is in the same function (handler1, handler2, etc.) with the part which handles the window closing event. If the arguments are null, it does the former, if it isn't (that means it was triggered by the user) it does the latter.
I need an extensible solution to this so that I can insert and remove dialogs anytime I want (the order and the pointers to the functions are stored in the CONTROLS field, and this seems to be very convenient, if you actually understand it. Although it is never easy to change the entire content of a form, there ought to be a simpler way to do this, as well a nicer one, that is what I'm looking for.
I hope this time I could explain how the model works.

I think it might be theoretically possible to make that code more delightfully diverting, perilously puckish, jovially jeopardous, cheerily chancy and unwarily whimsical but it would require some serious thought.

somehow your code makes me want to cry, i´m sorry. i read it twice and all i know about it is that it "doesStuff" with "STATES".
if you really want some help on this one you will have to work on it yourself first...

Use, XML! It's human-readable!
More seriously-
It seems like you're trying to create some sort of configuration wizard, so I'd start by researching that. Regarding your particular solution, I generally advocate very strongly against the "layered panel" approach. I do so because I maintain apps written by people who found this approach, or the related "hidden tabs on a tab control" approach, to be a good idea. It's not, and maintainers will curse your name for years to come.
That being said, what alternatives are there? Well, one alternative is what you've already dismissed because of its "flicker". I'd say that, in general, the flicker isn't that big of a deal for a quick and dirty application. It might be a good idea to make sure that your new window is called up before closing the old one, for example. (I'm assuming this is possible, I haven't developed on a mobile device.)
Another possibility might be a less-evil version of your layered panels. Instead of throwing a half-dozen panels into one form, create a separate user control for each wizard page and then add/remove the user controls to a containing form. This can avoid your flicker and will prove to be much easier to maintain because each page is in a different control. This might also ease any subsequent "Back" button functionality and make your data structures more naturally defined because those user controls will be associated with a specific logical bit of data. It's still not ideal, but it's probably good enough for a one-off solution.
A third technique, if you foresee extensive wizard modification as the product matures, might be to generalize the creation of your user controls by defining them in a more logical/declarative manner (e.g. via XML). If you dynamically generate sensible controls based on XML, then modifying the panels might be as easy as diving into your XML and doing something like:
<Questions>
<Question type="Text"> <!-- generate a textbox for the answer field -->
Favorite Color:
</Question>
<Question type="Number" range="0-255"> <!-- Maybe this is a spinner -->
The answer to life, the universe, and everything:
</Question>
</Questions>
That's just off the top of my head, and completely overkill for any one-off application, but it's a possibility.

Now, let me caveat this by saying this might work, but it may not be the answer to your real problem - that of a slow and unresponsive UI when you have a lot of forms. The real answer may be to just go ahead and do all separate forms, but have each form load its child forms in a background thread while the user is staring at the first form.
But assuming you're still set on this, I'd start off by making a separate class just to handle the Panel stacking/hierarchy. Call it PanelManager. You would instantiate the PanelManager and associate it with the main form, then add Panels to it (perhaps keyed to a String) and set the order. In the main form, have the closing handler call PanelManager.CloseCurrentPanel() and if there are no more Panels to show then it's time to close the main form.
Time for pseudo-code! Here's a quick idea for the class, i'll leave it to you to implement it:
public class PanelManager {
// constructor
public PanelManager (Form ownerForm);
// short-cut properties
public Panel this[int idx]
{ get; set; }
public int Index
{ get; set; }
// main functionality
public int AddPanel (Panel p);
public void SetPanelOrder (Panel p, int idx);
public void RemovePanel (Panel p);
public void RemovePanelAt (int idx);
// shows the first Panel
public void Show ();
// shows Panel[idx]
public void Show (int idx);
// adds the panel to the top of the stack and displays it
// returns the index of the panel
public int AddPanelAndShow (Panel p);
// hides the current panel, displays the one underneath it
// returns false if there are no more panels
public bool HideCurrentPanel ();
}
in the constructor for the main form, instantiate it by new PanelManager (this), then in the closing event handler, call panelManager.HideCurrentPanel () and then figure out whether or not you need to close it after that.