The page I am working on has a javascript function executed to print parts of the page. For some reason, printing in Safari, causes the window to somehow update. I say somehow, because it does not really refresh as in reload the page, but rather it starts the "rendering" of the page from start, i.e. scroll to top, flash animations start from 0, and so forth. The effect is reproduced by this fiddle: http://jsfiddle.net/fYmnB/ Clicking the print button and finishing or cancelling a print in Safari causes the screen to "go white" for a sec, which in my real website manifests itself as something "like" a reload. While running print button with, let's say, Firefox, just opens and closes the print dialogue without affecting the fiddle page in any way. Is there something with my way of calling the browsers print method that causes this, or how can it be explained - and preferably, avoided? P.S.: On my real site the same occurs with Chrome. In the ex
To give auto implemented properties a default value, you'd have to do it in the constructor.
ReplyDeleteWhen you inline an initial value for a variable it will be done implicitly in the constructor anyway.
ReplyDeleteI would argue that this syntax is best practice:
class Person
{
public Person()
{
//do anything before variable assignment
//assign initial values
Name = "Default Name";
//do anything after variable assignment
}
public string Name { get; set; }
}
As this gives you more clear control of the order values are assigned.
DefaultValueAttribute ONLY work in the vs designer. It will not initialize the property to that value.
ReplyDeleteSometimes I use this, if I don't want it to be actually set and persisted in my db:
ReplyDeleteclass Person
{
private string _name;
public string Name
{
get
{
return string.IsNullOrEmpty(_name) ? "Default Name" : _name;
}
set { _name = value; }
}
}
Obviously if it's not a string then I might make the object nullable ( double?, int? ) and check if it's null, return a default, or return the value it's set to.
Then I can make a check in my repository to see if it's my default and not persist, or make a backdoor check in to see the true status of the backing value, before saving.
Hope that helps!
Though the intended use of the attribute is not to actually set the values of the properties, you can use reflection to always set them anyway...The unintended consequences are not clear to me at the moment (e.g. if some Microsoft coder set the meta tag incorrectly, but actually defaulted it to something else in the constructor could you override that?)
ReplyDeleteAnyway...
public class DefaultValuesTest
{
public DefaultValuesTest()
{
foreach (PropertyDescriptor property in TypeDescriptor.GetProperties(this))
{
DefaultValueAttribute myAttribute = (DefaultValueAttribute)property.Attributes[typeof(DefaultValueAttribute)];
if (myAttribute != null)
{
property.SetValue(this, myAttribute.Value);
}
}
}
public void DoTest()
{
var db = DefaultValueBool;
var ds = DefaultValueString;
var di = DefaultValueInt;
}
[System.ComponentModel.DefaultValue(true)]
public bool DefaultValueBool { get; set; }
[System.ComponentModel.DefaultValue("Good")]
public string DefaultValueString { get; set; }
[System.ComponentModel.DefaultValue(27)]
public int DefaultValueInt { get; set; }
}
little complete sample:
ReplyDeleteprivate bool bShowGroup ;
[Description("Show the group table"), Category("Sea"),DefaultValue(true)]
public bool ShowGroup
{
get { return bShowGroup; }
set { bShowGroup = value; }
}
class Person
ReplyDelete{
/// Gets/sets a value indicating whether auto
/// save of review layer is enabled or not
[ System.ComponentModel.DefaultValue(true)]
public bool AutoSaveReviewLayer { get; set; }
}
Have you tried using the DefaultValueAttribute or ShouldSerialize and Reset methods in conjunction with the constructor? I feel like one of these two methods is necessary if you're making a class that might show up on the designer surface or in a property grid.
ReplyDeletePersonally, I don't see the point of making it a property at all if you're not going to do anything at all beyond the auto-property. Just leave it as a field. The encapsulation benefit for these item are just red herrings, because there's nothing behind them to encapsulate. If you ever need to change the underlying implementation you're still free to refactor them as properties without breaking any dependent code.
ReplyDeleteHmm... maybe this will be the subject of it's own question later
class Person
ReplyDelete{
private string _name;
[DefaultValue(true)]
public string Name
{
get { return _name; }
set { _name = value; }
}
}