This Application does one thing. It adds an explorer shell menu to folders that when selected will recursively delete the contents of the bin, obj and setup folders. If you have a .NET project that you wish to share with some one, this is useful to remove the unnecessary stuff from the folder before you zip it up and send it off.
Download Code Formatter Plugin
This new application updater is a new application updater component which is customizable and supports both WebDAV and BITS . BITS allows you to let the application download updates in the background, which means users would practically not notice anything, since BITS will use unused bandwidth.
Usage:
Add a reference to Updater.zip and implement the IAgent interface. Your IAgent implementation will be used for getting available updates and such.
When you've done that, you write your own download implementation in case you don't want to use WebDAV or BITS to download updates.
The next thing you got to do is initialize a new Updater, add eventhandlers, and that's basically all you got to do.
If you want to check for updates, you call the Refresh method on the Updater instance, when you've detected an update you call the Download method, and when you're done with updating and want to restart the application, you use the ApplyUpdate method.
Threading in C# An extensive article on multi-threading in C#. This tackles difficult issues such as thread safety, when to use Abort, Wait Handles vs Wait and Pulse, the implications of Apartment Threading in Windows Forms, using Thread Pooling, Synchronization Contexts, Memory Barriers and non-blocking synchronization constructs.
[Via Roy Osherove's Blog]
The default behavior for the splitter is to take focus once selected. If you want the splitter to be movable without taking focus you can do one of two things:
Insert the following code in your project, and attach these events to all of the SplitContainers that you don't want stealing focus.
// Temp variable to store a previously focused control
private Control focused = null;
private void splitContainer_MouseDown(object sender, MouseEventArgs e)
{
// Get the focused control before the splitter is focused
focused = getFocused(this.Controls);
}
private Control getFocused(Control.ControlCollection controls)
{
foreach (Control c in controls)
{
if (c.Focused)
{
// Return the focused control
return c;
}
else if (c.ContainsFocus)
{
// If the focus is contained inside a control's children
// return the child
return getFocused(c.Controls);
}
}
// No control on the form has focus
return null;
}
private void splitContainer_MouseUp(object sender, MouseEventArgs e)
{
// If a previous control had focus
if (focused != null)
{
// Return focus and clear the temp variable for
// garbage collection
focused.Focus();
focused = null;
}
}
If the splitter is not distinguishable from the rest of the split container, it is due to the SplitContainerPanels having the same background color as the splitter, and the BorderStyle being set to None. To make the splitter easily recognizable, change the BackColor for the SplitContainerPanels, or set the SplitContainer's BorderStyle.
If you want to select a SplitContainer control at design time, click on the splitter. If you click on either of the SplitContainerPanels, you will select them instead. Also you can use the drop down menu in the property grid to select the SplitContainer by name. Finally you can use the Document Outline to select the SplitContainer and control the Z-order of the controls within it.
How do I persist application settings in the registry?
For information on using the registry for settings, see the following SDK sample: http://msdn2.microsoft.com/en-us/library/ms181001.aspx
For information on using the a Web service for settings, see the following SDK sample: http://msdn2.microsoft.com/en-us/library/ms180994.aspx
While most common types can be serialized in one of two ways listed above, there are some types that may not. In such cases, you have a few different options:
The LocalFileSettingsProvider does not provide a way to change the files in which settings are stored.
Note: The provider itself doesn't determine the config file locations in the first place - it is the configuration system.
If you need to store the settings in a different location for some reason, the recommended way is to write your own SettingsProvider. This is fairly simple to implement and you can find samples in the .NET 2.0 SDK that show how to do this. Keep in mind however that you may run into the same isolation issues mentioned above.
If you want to get to the path programmatically, you can do it using the Configuration Management API. For example, here is how you can get the local user.config file path:
Note: You need to add a reference to System.Configuration.dll
Configuration config =
ConfigurationManager.OpenExeConfiguration(
ConfigurationUserLevel.PerUserRoamingAndLocal);
Console.WriteLine("Local user config path: {0}", config.FilePath);
There are a couple of reasons why the user.config path is version sensitive:
The path construction algorithm has to meet certain rigorous requirements in terms of security, isolation and robustness. While we tried to make the path as easily discoverable as possible by making use of friendly, application supplied strings, it is not possible to keep the path totally simple without running into issues like collisions with other apps, spoofing etc.
The path of the user.config files is structured as follows:
<Profile Directory>\<Company Name>\<App Name>_<Evidence Type>_<Evidence Hash>\<Version>\user.config
Where:
Note: The file name is always simply 'user.config'
Application scoped settings are essentially read only from the application's point of view, and aren't meant to be changed by users, but rather only the administrator. An additional reason for this has to do with how the default SettingsProvider stores settings. Application scoped settings are stored in the exe configuration file, and user scoped settings are stored in user.config files located in the user data path. Generally, exe config files should not be written to at runtime by the application, since the user may not have access to them. In addition, it is normally not a good idea for a user to change a file that affects every other user of the application.
There are generally two main types of settings that applications want to store:
Application scoped settings are useful in scenario (1) and user scoped settings are useful in scenario (2).
